Feature #1964

MariaDB 10あるいは11でのmroongaバンドル

Added by Kouhei Sutou over 4 years ago. Updated about 4 years ago.

Status:要仕様議論Start date:03/04/2014
Priority:NormalDue date:
Assignee:Kenji Maruyama% Done:

60%

Category:-Estimated time:5.00 hours
Target version:-

Description

動機

mroongaをより速く改良していきたい。そのための方法として、mroongaが普及→ユーザー数・コントリビューター数増加→バグレポート・パッチ増加→mroongaがよくなる→mroongaがさらに普及→…といった正のスパイラルを実現するという案がある。

MariaDBにmroongaがバンドルされるとmroongaをインストールする作業が必要なくなるので導入の敷居を大きく下げることができ、mroongaの普及に繋げられるだろう。

ゴール

次期安定版のMariaDB 10あるいその次の安定版のMariaDB 11でのmroongaバンドルを目指す。

実現案

斯波さんはSpiderのMariaDBバンドルを実現しており、MariaDBにストレージエンジンをバンドルするまでの流れを把握している。それを活かしたい。そのため、斯波さん主導でMariaDB開発者への働きかけを行っていく。

それにあたり、mroonga自体の問題やMariaDB trunkへの対応なども斯波さんが対応する。ただし、groongaに関連する問題(groongaのバグの修正やgroongaの効率的な使い方など)や、ビルドシステムやテスト実行まわりの整備(たとえば、mroongaはtest/sql/以下にテストを置いているが、MariaDBではmroonga/mysql-test/以下にテストを置く流儀らしいのでそこは合わせたほうがよさそう)などは須藤が対応するので、そこは適宜タスクをふってもらうことにする。

現状

現在は、BUILD/compile-amd64-valgrind-maxでビルドしたMariaDB 10.0.4に対してmroongaのテストを実行するとすべてパス・valgrindのエラーもなし、という状態になっている。

ただし、MariaDBのtrunk(bzr branch lp:maria trunkで持ってこれるやつ)で↑と同じことをするとSEGVする。

MariaDBにmroongaをマージする用のリポジトリはすでにlaunchpadに作ってある。→ https://code.launchpad.net/~mroonga

↑のリポジトリの内容を最新に更新するためのスクリプトも用意してある。使い方はREADME.mdを参照。 → https://github.com/mroonga/mariadb-sync

warnings.txt Magnifier (62.6 KB) Kentoku SHIBA, 10/20/2013 11:35 pm

groonga_error.txt Magnifier (17.5 KB) Kentoku SHIBA, 11/06/2013 03:46 am

embedded_result.log (46.8 KB) Kentoku SHIBA, 11/06/2013 03:56 am

CMakeError.log (82.1 KB) Kenji Maruyama, 11/11/2013 05:49 pm

sync_sh_error.txt Magnifier (4.87 KB) Kentoku SHIBA, 11/17/2013 04:26 pm

Log-FreeBSD.txt Magnifier (54.1 KB) Kenji Maruyama, 02/14/2014 09:47 pm


Subtasks

Support #2367: FreeBSD9.1上 でmktimeが失敗する完了Kenji Maruyama

Bug #2383: This table type requires a primary key新規

Bug #2384: Plugin is busy and will be uninstalled on shutdown新規

Bug #2385: 1時間ずれる完了Kenji Maruyama

Bug #2386: Duplicate entry完了Kenji Maruyama

History

#1 Updated by Kentoku SHIBA over 4 years ago

  • File warnings.txtMagnifier added
  • Status changed from 新規 to 担当者作業中
  • Assignee changed from Kentoku SHIBA to Kouhei Sutou
  • % Done changed from 0 to 10

すとうさん

mroongaはtest/sql/以下のテストをmroonga/mysql-test/mroonga以下に

include
storage
wrapper
となるように配置をお願いします。

また、groongaのビルド中に検出されたwarningを添付させて頂きますので、 お手数ですがこちらの対応方針のご検討をお願いします。

#2 Updated by Kouhei Sutou over 4 years ago

わかりました!

#3 Updated by Kouhei Sutou over 4 years ago

mysql-test/の方はやりましたー 確認おねがいします!

#4 Updated by Kouhei Sutou over 4 years ago

warningは↓以外はでないようにしました!↓はパーサージェネレータが自動生成するファイルなので勘弁してください。。。

In file included from /home/kou/work/cpp/maria/mroonga/storage/mroonga/vendor/groonga/lib/expr.c:5532:0:
ecmascript.c: In function ‘yy_destructor’:
ecmascript.c:73:45: warning: unused variable ‘efsi’ [-Wunused-variable]
 #define grn_expr_parserARG_FETCH  efs_info *efsi  = yypParser->efsi 
                                             ^
ecmascript.c:876:3: note: in expansion of macro ‘grn_expr_parserARG_FETCH’
   grn_expr_parserARG_FETCH;
   ^

#5 Updated by Kouhei Sutou over 4 years ago

  • Assignee changed from Kouhei Sutou to Kentoku SHIBA

#6 Updated by Kouhei Sutou over 4 years ago

ディレクトリ構成の変更に伴ってsync.shも変わっているのでgit pull --rebaseするのを忘れないでください!

#7 Updated by Kentoku SHIBA over 4 years ago

lp:~mroonga/maria/mroonga へpushし、マージ依頼を行った。
その結果、マージのタスクは以下で管理されることになった。
https://mariadb.atlassian.net/browse/MDEV-5222

#8 Updated by Kentoku SHIBA over 4 years ago

Windowsでビルドすると添付「groonga_error.txt」の内容でエラーになりましたので、
お手数ではございますが修正のご検討をお願いします。
mroongaもwarningが出ていたので対応しました。
ただ、groonga.hのGRN_HASH_EACHに引き渡すidが、GRN_HASH_EACHの
中で利用されていないようで、こちらもwarningになっておりますので、
できましたら修正をお願いします。

また、embedded serverモードでテストを行ったところ、エラーが検知されましたので
こちらは後ほど対応させて頂きます。

#9 Updated by daijiro MORI over 4 years ago

GRN_HASH_EACHについてですが、こちらもwarningの実際のメッセージを貼っていただいても良いでしょうか?

#10 Updated by Kentoku SHIBA over 4 years ago

daijiro MORI wrote:

GRN_HASH_EACHについてですが、こちらもwarningの実際のメッセージを貼っていただいても良いでしょうか?

こちらになります。

ha_mroonga.cpp(4705) : warning C4101: 'id' : unreferenced local variable

#11 Updated by daijiro MORI over 4 years ago

たびたびすみません。。 VC++のバージョンはいくつでしょうか?

#12 Updated by daijiro MORI over 4 years ago

VC++は、2008のExpress Editionでした!

#13 Updated by Kentoku SHIBA over 4 years ago

com.hを修正して頂き、GRN_HASH_EACHのwarningの対処後、再度ビルド環境を構築し
ビルドを行ってみたところ、libgroongaのリンク時に以下のエラーとなりました。

ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_copen が関数 _grn_ctx_connect で参照されました。
ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_send が関数 _grn_ctx_send で参照されました。
ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_recv が関数 _grn_ctx_recv で参照されました。
ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_close が関数 _grn_ctx_fin で参照されました。
ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_init が関数 _grn_init で参照されました。
ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_fin が関数 _grn_fin で参照されました。
db.obj : error LNK2019: 未解決の外部シンボル _grn_edge_dispatch が関数 _grn_load_ で参照されました。
db.obj : error LNK2019: 未解決の外部シンボル _grn_msg_open が関数 _grn_load_ で参照されました。
db.obj : error LNK2019: 未解決の外部シンボル _grn_edges_add_communicator が関数 _grn_load_ で参照されました。

#14 Updated by Kenji Maruyama over 4 years ago

http://redmine.groonga.org/issues/1964#note-13

  • 手元での再現を試みています。 何か手順の相違点があれば教えていただければありがたいです。よろしくお願い致します
  • 環境は Windows8.1 , Microsoft Visual Studio Express 2013 for Windows Desktop です。 Windows ソースからビルド ( http://groonga.org/ja/docs/install/windows.html ) しています。

ビルド手順はほぼ上記のリンク通りになっています。


groonga-3.0.9> cmake . -G "Visual Studio 12 Win64" -DCMAKE_INSTALL_PREFIX=C:\groonga
groonga-3.0.9> cmake --build . --config Release

#15 Updated by Kenji Maruyama over 4 years ago

  • 32bit 版 にて build してみた結果 を 貼り付けておきます。 groonga commit de1fff2e487f1e0db6673606eef018a8ca9e8d8f
  • http://redmine.groonga.org/issues/1964#note-13 の 以下 3つのエラーとは異なりますが、残りのエラーはこちらでも再現できました。
db.obj : error LNK2019: 未解決の外部シンボル _grn_edge_dispatch が関数 _grn_load_ で参照されました。
db.obj : error LNK2019: 未解決の外部シンボル _grn_msg_open が関数 _grn_load_ で参照されました。
db.obj : error LNK2019: 未解決の外部シンボル _grn_edges_add_communicator が関数 _grn_load_ で参照されました。
groonga-3.0.9> cmake . -G "Visual Studio 12" -DCMAKE_INSTALL_PREFIX=C:\groonga

-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE) 
-- Looking for dlfcn.h
-- Looking for dlfcn.h - not found
-- Looking for errno.h
-- Looking for errno.h - found
-- Looking for execinfo.h
-- Looking for execinfo.h - not found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for netdb.h
-- Looking for netdb.h - not found
-- Looking for netinet/in.h
-- Looking for netinet/in.h - not found
-- Looking for netinet/tcp.h
-- Looking for netinet/tcp.h - not found
-- Looking for signal.h
-- Looking for signal.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stdlib.h
-- Looking for stdlib.h - found
-- Looking for sys/mman.h
-- Looking for sys/mman.h - not found
-- Looking for sys/param.h
-- Looking for sys/param.h - not found
-- Looking for sys/resource.h
-- Looking for sys/resource.h - not found
-- Looking for sys/socket.h
-- Looking for sys/socket.h - not found
-- Looking for sys/sysctl.h
-- Looking for sys/sysctl.h - not found
-- Looking for sys/time.h
-- Looking for sys/time.h - not found
-- Looking for sys/timeb.h
-- Looking for sys/timeb.h - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for sys/wait.h
-- Looking for sys/wait.h - not found
-- Looking for time.h
-- Looking for time.h - found
-- Looking for ucontext.h
-- Looking for ucontext.h - not found
-- Looking for unistd.h
-- Looking for unistd.h - not found
-- Looking for _strnicmp
-- Looking for _strnicmp - found
-- Looking for _strtoui64
-- Looking for _strtoui64 - found
-- Looking for close
-- Looking for close - found
-- Looking for gmtime_r
-- Looking for gmtime_r - not found
-- Looking for localtime_r
-- Looking for localtime_r - not found
-- Looking for mkostemp
-- Looking for mkostemp - not found
-- Looking for open
-- Looking for open - found
-- Looking for read
-- Looking for read - found
-- Looking for strncasecmp
-- Looking for strncasecmp - not found
-- Looking for strtoull
-- Looking for strtoull - found
-- Looking for write
-- Looking for write - found
-- Looking for dlopen in dl
-- Looking for dlopen in dl - not found
-- Looking for backtrace in execinfo
-- Looking for backtrace in execinfo - not found
-- Looking for backtrace
-- Looking for backtrace - not found
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - not found
-- Looking for winsock2.h
-- Looking for winsock2.h - found
-- Looking for select in ws2_32
-- Looking for select in ws2_32 - not found
-- Looking for event_init in event
-- Looking for event_init in event - not found
-- Looking for msgpack_version in msgpack
-- Looking for msgpack_version in msgpack - not found
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/maru/Documents/GitHub/groonga

  • groonga-3.0.9> cmake --build . --config Release

InitializeBuildStatus:

  "libgroonga.dir\Release\libgroonga.tlog\unsuccessfulbuild" のタッチ タスクを実行しています。

CustomBuild:

  すべての出力が最新のものです。

ClCompile:

  すべての出力が最新のものです。

  すべての出力が最新のものです。

Link:

  C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\maru\Documents\GitHub\groonga\lib\Release\groonga.dll" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:"C:/Users/maru/Documents/GitHub/groonga/lib/Release/groonga.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Users/maru/Documents/GitHub/groonga/lib/Release/groonga.lib" /MACHINE:X86 /SAFESEH  /machine:X86 /DLL libgroonga.dir\Release\com.obj

  libgroonga.dir\Release\ctx.obj

  libgroonga.dir\Release\ctx_impl_mrb.obj

  libgroonga.dir\Release\dat.obj

  libgroonga.dir\Release\db.obj

  libgroonga.dir\Release\error.obj

  libgroonga.dir\Release\expr.obj

  libgroonga.dir\Release\geo.obj

  libgroonga.dir\Release\hash.obj

  libgroonga.dir\Release\ii.obj

  libgroonga.dir\Release\io.obj

  libgroonga.dir\Release\mrb.obj

  libgroonga.dir\Release\nfkc.obj

  libgroonga.dir\Release\normalizer.obj

  libgroonga.dir\Release\output.obj

  libgroonga.dir\Release\pat.obj

  libgroonga.dir\Release\plugin.obj

  libgroonga.dir\Release\proc.obj

  libgroonga.dir\Release\snip.obj

  libgroonga.dir\Release\store.obj

  libgroonga.dir\Release\str.obj

  libgroonga.dir\Release\string.obj

  libgroonga.dir\Release\token.obj

  libgroonga.dir\Release\tokenizer.obj

  libgroonga.dir\Release\util.obj

  "libgroonga.dir\Release\cursor-factory.obj"

  "libgroonga.dir\Release\file-impl.obj"

  libgroonga.dir\Release\file.obj

  "libgroonga.dir\Release\id-cursor.obj"

  "libgroonga.dir\Release\key-cursor.obj"

  "libgroonga.dir\Release\predictive-cursor.obj"

  "libgroonga.dir\Release\prefix-cursor.obj"

  libgroonga.dir\Release\trie.obj

  libgroonga.dir\Release\mrb_accessor.obj

  libgroonga.dir\Release\mrb_expr.obj

  libgroonga.dir\Release\mrb_obj.obj

     ライブラリ C:/Users/maru/Documents/GitHub/groonga/lib/Release/groonga.lib とオブジェクト C:/Users/maru/Documents/GitHub/groonga/lib/Release/groonga.exp を作成中

com.obj : error LNK2019: 未解決の外部シンボル ___WSAFDIsSet@8 が関数 _grn_com_event_poll で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__accept@12 が関数 _grn_com_receiver で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__bind@12 が関数 _grn_com_sopen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__closesocket@4 が関数 _grn_com_close_ で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__connect@12 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__htonl@4 が関数 _grn_com_send で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__htons@4 が関数 _grn_com_sopen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__listen@8 が関数 _grn_com_event_start_accept で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__ntohl@4 が関数 _grn_com_recv で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__recv@16 が関数 _grn_com_recv で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__select@20 が関数 _grn_com_event_poll で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__send@16 が関数 _grn_com_send で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__setsockopt@20 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__shutdown@8 が関数 _grn_com_close_ で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__socket@12 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__WSAStartup@8 が関数 _grn_com_init で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__WSACleanup@0 が関数 _grn_com_fin で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

io.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

plugin.obj : error LNK2019: 未解決の外部シンボル __imp__WSAGetLastError@0 が関数 _grn_plugins_fin で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

ctx.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

error.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

ii.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__WSASend@28 が関数 _grn_com_send で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__getaddrinfo@16 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

com.obj : error LNK2019: 未解決の外部シンボル __imp__freeaddrinfo@4 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

ctx.obj : error LNK2019: 未解決の外部シンボル __imp__ntohs@4 が関数 _grn_ctx_recv で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

C:\Users\maru\Documents\GitHub\groonga\lib\Release\groonga.dll : fatal error LNK1120: 22 件の未解決の外部参照 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

プロジェクト "C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj" (既定のターゲット) のビルドが終了しました -- 失敗。

プロジェクト "C:\Users\maru\Documents\GitHub\groonga\src\groonga.vcxproj" (既定のターゲット) のビルドが終了しました -- 失敗。

プロジェクト "C:\Users\maru\Documents\GitHub\groonga\ALL_BUILD.vcxproj" (既定のターゲット) のビルドが終了しました -- 失敗。



ビルドに失敗しました。



"C:\Users\maru\Documents\GitHub\groonga\ALL_BUILD.vcxproj" (既定のターゲット) (1) ->

"C:\Users\maru\Documents\GitHub\groonga\src\groonga.vcxproj" (既定のターゲット) (3) ->

"C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj" (既定のターゲット) (4) ->

(Link ターゲット) -> 

  com.obj : error LNK2019: 未解決の外部シンボル ___WSAFDIsSet@8 が関数 _grn_com_event_poll で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__accept@12 が関数 _grn_com_receiver で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__bind@12 が関数 _grn_com_sopen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__closesocket@4 が関数 _grn_com_close_ で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__connect@12 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__htonl@4 が関数 _grn_com_send で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__htons@4 が関数 _grn_com_sopen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__listen@8 が関数 _grn_com_event_start_accept で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__ntohl@4 が関数 _grn_com_recv で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__recv@16 が関数 _grn_com_recv で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__select@20 が関数 _grn_com_event_poll で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__send@16 が関数 _grn_com_send で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__setsockopt@20 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__shutdown@8 が関数 _grn_com_close_ で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__socket@12 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__WSAStartup@8 が関数 _grn_com_init で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__WSACleanup@0 が関数 _grn_com_fin で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  io.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  plugin.obj : error LNK2019: 未解決の外部シンボル __imp__WSAGetLastError@0 が関数 _grn_plugins_fin で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  ctx.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  error.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  ii.obj : error LNK2001: 外部シンボル "__imp__WSAGetLastError@0" は未解決です。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__WSASend@28 が関数 _grn_com_send で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__getaddrinfo@16 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  com.obj : error LNK2019: 未解決の外部シンボル __imp__freeaddrinfo@4 が関数 _grn_com_copen で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  ctx.obj : error LNK2019: 未解決の外部シンボル __imp__ntohs@4 が関数 _grn_ctx_recv で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]

  C:\Users\maru\Documents\GitHub\groonga\lib\Release\groonga.dll : fatal error LNK1120: 22 件の未解決の外部参照 [C:\Users\maru\Documents\GitHub\groonga\lib\libgroonga.vcxproj]



    0 個の警告

    28 エラー


#16 Updated by Kenji Maruyama over 4 years ago

  • grn_com_xxx 関連で 未解決の外部シンボル は ws2_32.lib 絡み の気がしますが、 cmake (version 2.8.12) で Looking for select in ws2_32 - not found になっていますが、実機上で検索すると、WS2_32.lib が 存在しているようです。CMakeList.txt の以下の所 でちゃんとライブラリを探せていない? のような気もしますが。。。

  • 追記: 実機上で検索してWS2_32.lib が存在しない場合は、Windows PlatformSDK を使うと良い という古い記事がありますが、最新版のVS はいらないかも です。


if(WIN32)
  ac_check_headers(winsock2.h)
  if(NOT ${HAVE_WINSOCK2_H} EQUAL 1)
    message(FATAL_ERROR "No winsock2.h found")
  endif()
  ac_check_lib(ws2_32 select)
  if(NOT ${HAVE_WS2_32_LIB} EQUAL 1)
    message(FATAL_ERROR "select() isn't found in ws2_32.lib")
  endif()
  set(USE_SELECT TRUE)

#17 Updated by Kenji Maruyama over 4 years ago

  • 以下の手順で 手元で 32bit groonga を build, install できました。
手順
CMakeList.txt の  ac_check_lib(ws2_32 select)  を ac_check_lib(ws2_32 printf) に 修正 (なんか場当たり的な感じがしますが、こちらに直すと見つけてくれます。)
                           if(NOT ${HAVE_WS2_32_LIB} EQUAL 1) を  if(NOT ${HAVE_LIBWS2_32} EQUAL 1)  に 修正 (こちらは無影響だが、マクロ定義(以下) をみるとこちらのほうが正しいと思います)

macro(ac_check_lib library function)
  string(REGEX REPLACE "[/.]" "_" output_variable_base_name ${library})
  string(TOUPPER "${output_variable_base_name}" output_variable_base_name)
  set(output_variable_name "HAVE_LIB${output_variable_base_name}")

修正後、
del .¥CMakeCache.txt
cmake . -G "Visual Studio 12" -DCMAKE_INSTALL_PREFIX=C:\groonga
cmake --build . --config Release
cmake --build . --config Release --target Install

#18 Updated by Kenji Maruyama over 4 years ago

ac_check_lib(ws2_32 select) 時 の CMakeError.log を添付しておきます。(環境 windows8.1 , VS Express 2013 for desktop, cmake 2.8.12) http://redmine.groonga.org/issues/1964#note-15 と同じ手順で実行

#19 Updated by Kouhei Sutou over 4 years ago

64bit用ビルドだとselectでfoundになって、32bit用ビルドだとselectでnot foundになるみたいです!

普通にVisual Studioで↓みたいなプログラムを作って32bit用ビルドにしてws2_32.libを使ってもエラーになるか試すと何かわかるかもです!

#include <winsock2.h>

int
main(void)
{
  select(0, NULL, NULL, NULL, NULL);
  return 0;
}

#20 Updated by Kenji Maruyama over 4 years ago

http://redmine.groonga.org/issues/1964#note-19

普通にプロジェクトを作り、上記のソースコードをwin32でbuildしてみた結果、正常終了しました。

リンカ > 入力 > 追加する依存関係 にws2_32.lib を 追加しても結果 変わりませんでした。

#21 Updated by Kentoku SHIBA over 4 years ago

丸山さんの修正をこちらの環境(Windows7 32bit)試してみたところ、
VS Express 2010だとビルドできるようになり、
VS Express 2008だと以下のエラーが残った状態になりました。

1>ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_copen が関数 _grn_ctx_connect で参照されました。
1>ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_send が関数 _grn_ctx_send で参照されました。
1>ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_recv が関数 _grn_ctx_recv で参照されました。
1>ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_close が関数 _grn_ctx_fin で参照されました。
1>ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_init が関数 _grn_init で参照されました。
1>ctx.obj : error LNK2019: 未解決の外部シンボル _grn_com_fin が関数 _grn_fin で参照されました。
1>db.obj : error LNK2019: 未解決の外部シンボル _grn_edge_dispatch が関数 _grn_load_ で参照されました。
1>db.obj : error LNK2019: 未解決の外部シンボル _grn_msg_open が関数 _grn_load_ で参照されました。
1>db.obj : error LNK2019: 未解決の外部シンボル _grn_edges_add_communicator が関数 _grn_load_ で参照されました。
1>C:\temp\vendor_groonga\groonga\lib\Release\groonga.dll : fatal error LNK1120: 外部参照 9 が未解決です。

ビルド手順は、以下を利用しています。(Cygwin利用)

VS Express 2010

/cygdrive/c/Program\ Files/CMake\ 2.8/bin/cmake . -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX="C:\groonga"
cmake --build . --config Release

VS Express 2008

/cygdrive/c/Program\ Files/CMake\ 2.8/bin/cmake . -G "Visual Studio 9 2008" -DCMAKE_INSTALL_PREFIX="C:\groonga"
cmake --build . --config Release

#22 Updated by Kenji Maruyama over 4 years ago

http://redmine.groonga.org/issues/1964#note-20

2013/11/12 追記: VS2013 for Win8 をアンインストールして、buildし直してみました。

  • winsock2.h は VS2013 for Win8 と VS2013 for Desktop 併用時点でも winsock2.h - found になっていました。
  • ac_check_lib(ws2_32 select) は アンインストール後でも select in ws2_32 not found になります。アンインストール前と状態変わりません。。。

#23 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

丸山さんの修正をこちらの環境(Windows7 32bit)試してみたところ、

VS Express 2010だとビルドできるようになり、

VS Express 2008だと以下のエラーが残った状態になりました。

MariaDBが対応しているVisual Studioの一番低いバージョンっていくつかわかりますか?

もし、2010以降なら2008のサポートは捨てたいです!

#24 Updated by Kouhei Sutou over 4 years ago

Kenji Maruyama wrote:

http://redmine.groonga.org/issues/1964#note-19


普通にプロジェクトを作り、上記のソースコードをwin32でbuildしてみた結果、正常終了しました。


リンカ > 入力 > 追加する依存関係 にws2_32.lib を 追加しても結果 変わりませんでした。

CMakeError.logをみると以下のようになっています。これと同じコマンドを使うと同じ状況を再現できないものでしょうか。。。

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D CHECK_FUNCTION_EXISTS=select /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec1314219151.dir\Debug\" /Fd"cmTryCompileExec1314219151.dir\Debug\vc120.pdb" /Gd /TC /analyze- /errorReport:queue "C:\Program Files (x86)\CMake 2.8\share\cmake-2.8\Modules\CheckFunctionExists.c"
Microsoft(R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.


cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D CHECK_FUNCTION_EXISTS=select /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec1314219151.dir\Debug\" /Fd"cmTryCompileExec1314219151.dir\Debug\vc120.pdb" /Gd /TC /analyze- /errorReport:queue "C:\Program Files (x86)\CMake 2.8\share\cmake-2.8\Modules\CheckFunctionExists.c"


CheckFunctionExists.c
Link:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\maru\Documents\GitHub\groonga\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec1314219151.exe" /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib ws2_32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:/Users/maru/Documents/GitHub/groonga/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec1314219151.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Users/maru/Documents/GitHub/groonga/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec1314219151.lib" /MACHINE:X86 /SAFESEH /machine:X86 /debug cmTryCompileExec1314219151.dir\Debug\CheckFunctionExists.obj
CheckFunctionExists.obj : error LNK2019: 未解決の外部シンボル _select が関数 _main で参照されました。 [C:\Users\maru\Documents\GitHub\groonga\CMakeFiles\CMakeTmp\cmTryCompileExec1314219151.vcxproj]
C:\Users\maru\Documents\GitHub\groonga\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec1314219151.exe : fatal error LNK1120: 1 件の未解決の外部参照 [C:\Users\maru\Documents\GitHub\groonga\CMakeFiles\CMakeTmp\cmTryCompileExec1314219151.vcxproj]
プロジェクト "C:\Users\maru\Documents\GitHub\groonga\CMakeFiles\CMakeTmp\cmTryCompileExec1314219151.vcxproj" (既定のターゲット) のビルドが終了しました -- 失敗。

#25 Updated by Kouhei Sutou over 4 years ago

  • Assignee changed from daijiro MORI to Kenji Maruyama

C:\Program Files (x86)\CMake 2.8\share\cmake-2.8\Modules\CheckFunctionExists.c の中身がどうなっているのかも気になりますね。CHECK_FUNCTION_EXISTSというマクロでチェックしたい関数名を指定していると思うんですけど。。。

#26 Updated by Kenji Maruyama over 4 years ago

#24

以下実行してみると、CheckFuntionExists.obj が生成されていますね。

tmpファイルのパスを変更, オプション /Zi を /MP に変更(複数のCL.EXEが同じ.PDBファイルに書き込む場合, /FSを使用してくださいに対応するため、/MPにするデフォルトで/FSになる。http://msdn.microsoft.com/en-us/library/vstudio/dn502518.aspx )

その後に、linkの挙動がちがいます。OUT: と /PDB: と IMPLIB と 先ほど生成した CheckFuntionExists.obj のパスを変更、後は一緒ですが。ファイル 'kernel32.lib' を開くことができませんとなります。

PS C:¥Program Files (x86)¥Microsoft Visual Studio 12.0¥VC¥bin> .¥CL.exe /MP /c /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDO
WS /D CHECK_FUNCTION_EXISTS=select /D _DEBUG  /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"C:¥U
sers¥maru¥¥" /Fd"c:¥Users¥maru¥vc101.pdb" /Gd /TC /analyze- /errorReport:queue "C:¥Program Files (x86)¥CMake 2.8¥share¥c
make-2.8¥Modules¥CheckFunctionExists.c"

同日追記: 

PS C:¥Program Files (x86)¥Microsoft Visual Studio 12.0¥VC¥bin> ./link.exe /ERRORREPORT:QUEUE /OUT:"C:¥Users¥maru¥a.exe"
/INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32
.lib advapi32.lib ws2_32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:
/Users/maru/a.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:¥Users¥maru¥a.lib" /MACHINE:X86 /SAFESE
H /machine:X86 /debug C:¥Users¥maru¥CheckFunctionExists.obj
LINK : fatal error LNK1104: ファイル 'kernel32.lib' を開くことができません。

#25

CheckFunctionExists.c

1 #ifdef CHECK_FUNCTION_EXISTS
  2
  3 char CHECK_FUNCTION_EXISTS();
  4 #ifdef __CLASSIC_C__
  5 int main(){
  6   int ac;
  7   char*av[];
  8 #else
  9 int main(int ac, char*av[]){
 10 #endif
 11   CHECK_FUNCTION_EXISTS();
 12   if(ac > 1000)
 13     {
 14     return *av[0];
 15     }
 16   return 0;
 17 }
 18
 19 #else  /* CHECK_FUNCTION_EXISTS */
 20
 21 #  error "CHECK_FUNCTION_EXISTS has to specify the function"
 22
 23 #endif /* CHECK_FUNCTION_EXISTS */

CheckFunctionExists.cmake

32 macro(CHECK_FUNCTION_EXISTS FUNCTION VARIABLE)
 33   if("${VARIABLE}" MATCHES "^${VARIABLE}$")
 34     set(MACRO_CHECK_FUNCTION_DEFINITIONS
 35       "-DCHECK_FUNCTION_EXISTS=${FUNCTION} ${CMAKE_REQUIRED_FLAGS}")
 36     message(STATUS "Looking for ${FUNCTION}")
 37     if(CMAKE_REQUIRED_LIBRARIES)
 38       set(CHECK_FUNCTION_EXISTS_ADD_LIBRARIES
 39         LINK_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES})
 40     else()
 41       set(CHECK_FUNCTION_EXISTS_ADD_LIBRARIES)
 42     endif()
 43     if(CMAKE_REQUIRED_INCLUDES)
 44       set(CHECK_FUNCTION_EXISTS_ADD_INCLUDES
 45         "-DINCLUDE_DIRECTORIES:STRING=${CMAKE_REQUIRED_INCLUDES}")
 46     else()
 47       set(CHECK_FUNCTION_EXISTS_ADD_INCLUDES)
 48     endif()
 49     try_compile(${VARIABLE}
 50       ${CMAKE_BINARY_DIR}
 51       ${CMAKE_ROOT}/Modules/CheckFunctionExists.c
 52       COMPILE_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS}
 53       ${CHECK_FUNCTION_EXISTS_ADD_LIBRARIES}
 54       CMAKE_FLAGS -DCOMPILE_DEFINITIONS:STRING=${MACRO_CHECK_FUNCTION_DEFINITIONS}
 55       "${CHECK_FUNCTION_EXISTS_ADD_INCLUDES}"
 56       OUTPUT_VARIABLE OUTPUT)
 57     if(${VARIABLE})
 58       set(${VARIABLE} 1 CACHE INTERNAL "Have function ${FUNCTION}")
 59       message(STATUS "Looking for ${FUNCTION} - found")
 60       file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
 61         "Determining if the function ${FUNCTION} exists passed with the following output:\n"
 62         "${OUTPUT}\n\n")
 63     else()
 64       message(STATUS "Looking for ${FUNCTION} - not found")
 65       set(${VARIABLE} "" CACHE INTERNAL "Have function ${FUNCTION}")
 66       file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log
 67         "Determining if the function ${FUNCTION} exists failed with the following output:\n"
 68         "${OUTPUT}\n\n")
 69     endif()
 70   endif()
 71 endmacro()

#27 Updated by Kenji Maruyama over 4 years ago

  • CMake version を少しずつ 落としてみて、buildできるかどうか やってみます。
  • CMake で 直接 ws2_32.lib の path をset してみて、buildできるかどうか やってみます。

#28 Updated by Kouhei Sutou over 4 years ago

うーん、違うエラーがでるってことですね。

どうして、kenrel32.libすら見つからないのかしら。。。

これって、Visual Studioがスタートメニューに登録するコマンドプロンプトからやっているんですよね?そしたらもろもろの環境変数は設定されていてkernel32.libくらい見つかりそうですが。。。

#29 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

Kentoku SHIBA wrote:

丸山さんの修正をこちらの環境(Windows7 32bit)試してみたところ、

VS Express 2010だとビルドできるようになり、

VS Express 2008だと以下のエラーが残った状態になりました。


MariaDBが対応しているVisual Studioの一番低いバージョンっていくつかわかりますか?


もし、2010以降なら2008のサポートは捨てたいです!

今のところ2008もサポートしているようです。 https://mariadb.com/kb/en/Building_MariaDB_on_Windows/

#30 Updated by Kenji Maruyama over 4 years ago

#28

64bit Windows8.1 の VS2013 for Desktop では、32bit用のライブラリ kenrel32.lib, ws2_32.lib が ないので、パスにも設定されてないのが原因かと思います。 以下のパスを設定することで、 #24 と同じ現象を再現できました。 別途Windows SDKが必要です。。。 現時点では、CMake は windows sdk のパスまで探しに行っていないように見えます kernel32.lib と ws2_32.lib が同じパスにあるので、単純に ac_check_lib(ws2_32 select) で select が見つからないだけの可能性ありますね。


SET PATH=C:\Program Files (x86)\Windows Kits\8.1\bin\x86;%PATH%
SET INCLUDE=C:\Program Files (x86)\Windows Kits\8.1\Include\um;%INCLUDE%
SET LIB=C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86;%LIB%

SET LIB=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib;%LIB%

#31 Updated by Kentoku SHIBA over 4 years ago

sync.shの中の「bzr branch lp:maria trunk」が 以前は問題なく動作していたが、添付のエラーになるようになった。 work/maria配下を作り直してもエラーは解消されず、 現在、別環境で確認中。

#32 Updated by Kentoku SHIBA over 4 years ago

別環境ではsync.shは正常に動作した。
embeddedでのテストのエラーを詳細に確認したところ、alter tableやUDFなどの挙動に
不明点が出てきたため確認中。

#33 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

Kouhei Sutou wrote:

Kentoku SHIBA wrote:

丸山さんの修正をこちらの環境(Windows7 32bit)試してみたところ、

VS Express 2010だとビルドできるようになり、

VS Express 2008だと以下のエラーが残った状態になりました。


MariaDBが対応しているVisual Studioの一番低いバージョンっていくつかわかりますか?


もし、2010以降なら2008のサポートは捨てたいです!


今のところ2008もサポートしているようです。 https://mariadb.com/kb/en/Building_MariaDB_on_Windows/

おぉ。。。そうですか。。。では、がんばりますか。。。

最初、 __declspec(dllexport) が足りないのかなぁと思ったのですが、これが付いていてもリンクできていないシンボルがあるんですよねぇ。しかも、すべて、com.cで定義しているものばかり。

ということで、「com」という名前が悪いんじゃないかと思います。確認するために、↓のときに実行しているコマンドを教えてもらえないでしょうか?たぶん、ログに入っていると思います。

1>C:\temp\vendor_groonga\groonga\lib\Release\groonga.dll : fatal error LNK1120: 外部参照 9 が未解決です。

#34 Updated by Kouhei Sutou over 4 years ago

Kenji Maruyama wrote:

#28


64bit Windows8.1 の VS2013 for Desktop では、32bit用のライブラリ kenrel32.lib, ws2_32.lib が ないので、パスにも設定されてないのが原因かと思います。 以下のパスを設定することで、 #24 と同じ現象を再現できました。 別途Windows SDKが必要です。。。 現時点では、CMake は windows sdk のパスまで探しに行っていないように見えます kernel32.lib と ws2_32.lib が同じパスにあるので、単純に ac_check_lib(ws2_32 select) で select が見つからないだけの可能性ありますね。

たぶん、Visual Studio(devenv.exe)の初期化時にws2_32.libがあるところにパスを設定しているんですね。

で、cmakeはVisual Studio経由じゃなくて、直接link.exeを呼んでいるのでそのパスが設定されていなくてws2_32.libが見つけられないんでしょう。

もやっとしますが、今のところはWindows上では常にws2_32.libがあると仮定しても大丈夫だと ac_check_lib() をしないで必要な変数を設定するようにしました。

これで、ws2_32.lib問題が解決するといいなぁ。。。


SET PATH=C:\Program Files (x86)\Windows Kits\8.1\bin\x86;%PATH%
SET INCLUDE=C:\Program Files (x86)\Windows Kits\8.1\Include\um;%INCLUDE%
SET LIB=C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86;%LIB%
SET LIB=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib;%LIB%

#35 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

ということで、「com」という名前が悪いんじゃないかと思います。確認するために、↓のときに実行しているコマンドを教えてもらえないでしょうか?たぶん、ログに入っていると思います。


1>C:\temp\vendor_groonga\groonga\lib\Release\groonga.dll : fatal error LNK1120: 外部参照 9 が未解決です。

直前ということは、これでしょうか?

link.exe @c:\temp\vendor_groonga\groonga\lib\libgroonga.dir\Release\RSP00000180647432.rsp /NOLOGO /ERRORREPORT:QUEUE

#36 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

Kouhei Sutou wrote:

ということで、「com」という名前が悪いんじゃないかと思います。確認するために、↓のときに実行しているコマンドを教えてもらえないでしょうか?たぶん、ログに入っていると思います。


1>C:\temp\vendor_groonga\groonga\lib\Release\groonga.dll : fatal error LNK1120: 外部参照 9 が未解決です。

直前ということは、これでしょうか?


link.exe @c:\temp\vendor_groonga\groonga\lib\libgroonga.dir\Release\RSP00000180647432.rsp /NOLOGO /ERRORREPORT:QUEUE

うーん、さすがにこれだとわかりませんね。。。

Visual Studio 2008を諦めたら、支障がでますよねぇ、やっぱり。。。

#37 Updated by Kenji Maruyama over 4 years ago

CMake version を少しずつ 落としてみて、buildできるかどうか やってみます。

cmake . -G "Visual Studio 12" で build できるのは 2.8.11.2 からで、すべて select in ws2_32 not found となりました。

今のところはWindows上では常にws2_32.libがあると仮定しても大丈夫だと ac_check_lib() をしないで必要な変数を設定するようにしました。これで、ws2_32.lib問題が解決するといいなぁ。。。

手元の環境で、groonga インストールまでできていることを確認できています!

#38 Updated by Kentoku SHIBA over 4 years ago

embeddedではUDFはサポートされていないということで、
embeddedテストの際にはUDFを使用しているテストを
スキップするようにしました。

#39 Updated by Kouhei Sutou over 4 years ago

Kenji Maruyama wrote:

CMake version を少しずつ 落としてみて、buildできるかどうか やってみます。


cmake . -G "Visual Studio 12" で build できるのは 2.8.11.2 からで、すべて select in ws2_32 not found となりました。

確認ありがとうございます!CMake 2.8.10が2012/11/07リリースなので、Visual Studio 12(= 2013)対応は2013/05/22リリースのCMake 2.8.11からというのはうなずけますね。

今のところはWindows上では常にws2_32.libがあると仮定しても大丈夫だと ac_check_lib() をしないで必要な変数を設定するようにしました。これで、ws2_32.lib問題が解決するといいなぁ。。。


手元の環境で、groonga インストールまでできていることを確認できています!

確認ありがとうございます!ちゃんとチェックしていないのは気持ち悪いですがこれでいきましょう!

#40 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

Visual Studio 2008を諦めたら、支障がでますよねぇ、やっぱり。。。

確認してみましたが、やはりVisual Studio 2008はまだサポートしているそうです。

#41 Updated by Kenji Maruyama over 4 years ago

  • Status changed from 担当者作業中 to 要仕様議論

#42 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

ということで、「com」という名前が悪いんじゃないかと思います。

ファイル名を「com」→「comm」に変えてみましたが、同じエラーになりました。

#43 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

Kouhei Sutou wrote:

ということで、「com」という名前が悪いんじゃないかと思います。


ファイル名を「com」→「comm」に変えてみましたが、同じエラーになりました。

外れていましたか。。。すみません。。。

環境を作って調べてみないといけなそうですね。。。 これ、いつぐらいまでに直っているとバンドルプロセスに支障がなさそうでしょうか? それとも、もうこれがブロッカーになっていたりしますか?

#44 Updated by Kenji Maruyama over 4 years ago

Visual Studio 2008を諦めたら、支障がでますよねぇ、やっぱり。。。

VS2008 は Microsoft社は もう 2013/04/09 で メインストリーム サポート終了 ( http://support.microsoft.com/lifecycle/?p1=12913 ) に なっていますね。。。

#45 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

Kentoku SHIBA wrote:

Kouhei Sutou wrote:

ということで、「com」という名前が悪いんじゃないかと思います。


ファイル名を「com」→「comm」に変えてみましたが、同じエラーになりました。


外れていましたか。。。すみません。。。


環境を作って調べてみないといけなそうですね。。。
これ、いつぐらいまでに直っているとバンドルプロセスに支障がなさそうでしょうか?
それとも、もうこれがブロッカーになっていたりしますか?

まだブロッカーにはなっていません。いつぐらいまでに直っているといいかはいまのところ正確なところは
見えないのですが、ひとまずは12月の中旬ぐらい完了をめどにして頂けるとありがたいです。

#46 Updated by Kentoku SHIBA over 4 years ago

Kenji Maruyama wrote:

Visual Studio 2008を諦めたら、支障がでますよねぇ、やっぱり。。。


VS2008 は Microsoft社は もう 2013/04/09 で メインストリーム サポート終了 ( http://support.microsoft.com/lifecycle/?p1=12913 ) に なっていますね。。。

なるほど。ではそのネタでもう一回確認してみます。

#47 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

Kenji Maruyama wrote:

Visual Studio 2008を諦めたら、支障がでますよねぇ、やっぱり。。。


VS2008 は Microsoft社は もう 2013/04/09 で メインストリーム サポート終了 ( http://support.microsoft.com/lifecycle/?p1=12913 ) に なっていますね。。。


なるほど。ではそのネタでもう一回確認してみます。

おぉ!よろしくおねがいします!

それでもサポートするよ、ということであれば、12月中旬を目処に確認してみます。。。

#48 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

Kentoku SHIBA wrote:

Kenji Maruyama wrote:

Visual Studio 2008を諦めたら、支障がでますよねぇ、やっぱり。。。


VS2008 は Microsoft社は もう 2013/04/09 で メインストリーム サポート終了 ( http://support.microsoft.com/lifecycle/?p1=12913 ) に なっていますね。。。


なるほど。ではそのネタでもう一回確認してみます。


おぉ!よろしくおねがいします!


それでもサポートするよ、ということであれば、12月中旬を目処に確認してみます。。。

プラグイン単位でサポートしていないものはビルドから外れていいそうなので、
バージョンを確認してVS2008以前だった場合、Mroongaのビルドは行わないようにしてみました。

#49 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

プラグイン単位でサポートしていないものはビルドから外れていいそうなので、
バージョンを確認してVS2008以前だった場合、Mroongaのビルドは行わないようにしてみました。

ありがとうございます! (ぜんぜん12月中旬を目処に確認していなくてすみません。。。)

これで、Mroongaバンドルの障壁はなくなった感じでしょうか!?

#50 Updated by Kentoku SHIBA over 4 years ago

Kouhei Sutou wrote:

Kentoku SHIBA wrote:

プラグイン単位でサポートしていないものはビルドから外れていいそうなので、
バージョンを確認してVS2008以前だった場合、Mroongaのビルドは行わないようにしてみました。


ありがとうございます!
(ぜんぜん12月中旬を目処に確認していなくてすみません。。。)


これで、Mroongaバンドルの障壁はなくなった感じでしょうか!?

こちらの対応で、これができていないと先に進めないというのはない状態です。
この後テストなどで問題がみつかると随時対応を行い、
そのあたりが片付いてバンドルという流れになる予定です。

#51 Updated by Kouhei Sutou over 4 years ago

Kentoku SHIBA wrote:

こちらの対応で、これができていないと先に進めないというのはない状態です。

よかったです!

この後テストなどで問題がみつかると随時対応を行い、
そのあたりが片付いてバンドルという流れになる予定です。

なるほど!とすると、10.0.7か、遅くとも10.0.8にはバンドルしてもらえそうですね!

#52 Updated by Kenji Maruyama over 4 years ago

③ の FreeBSD 9.1上における MariaDB 10(mroonga bundle) テストが失敗する件について

添付ファイルのログをみても、すべてtime関係でテスト失敗になっています。

おそらく共通する要因でテスト失敗になっていると思われるので、その中の一つについて以下原因を調査してみました。

DROP TABLE IF EXISTS diaries;

CREATE TABLE diaries (
  id INT PRIMARY KEY AUTO_INCREMENT,
  title TEXT,
  created_at DATETIME
) ENGINE='mroonga' DEFAULT CHARSET UTF8;
SHOW CREATE TABLE diaries;

INSERT INTO diaries (title, created_at)
       VALUES ('1000-01-01 00:00:00', '1000-01-01 00:00:00');

SELECT * FROM diaries;

期待する結果は以下ですが、

id  title   created_at
1   1000-01-01 00:00:00 1000-01-01 00:00:00

FreeBSD9.1上では以下になっています。

id  title   created_at
1   1000-01-01 00:00:00 1970-01-01 00:00:00

CentOS6.4上にてMySQL5.6で同じテスト(期待する結果を出力)した時のトレースログとFreeBSD9.1上でのトレースログで time について異なる箇所が以下になります。

mrn_time_converter.cpp の grn_time_to_mysql_time の GRN_TIME_UNPACK(grn_time, sec, usec) 後の値.

FreeBSD9.1 MariaDB10.0.8

T@6    : | | | | | | | | | | | | | | | | >mrn::TimeConverter::grn_time_to_mysql_time
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: sec=0
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: usec=0
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: MYSQL_TIMESTAMP_DATETIME
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: tm_year=70
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: tm_mon=0
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: tm_mday=1
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: tm_hour=0
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: tm_min=0
T@6    : | | | | | | | | | | | | | | | | | info: mroonga: tm_sec=0
T@6    : | | | | | | | | | | | | | | | | <mrn::TimeConverter::grn_time_to_mysql_time

CentOS6.4 MySQL5.6

72384 T@3    : | | | | | | | | | | | | | | | >mrn::TimeConverter::grn_time_to_mysql_time
72385 T@3    : | | | | | | | | | | | | | | | | info: mroonga: sec=-30610224000
72386 T@3    : | | | | | | | | | | | | | | | | info: mroonga: usec=0
72387 T@3    : | | | | | | | | | | | | | | | | info: mroonga: MYSQL_TIMESTAMP_DATETIME
72388 T@3    : | | | | | | | | | | | | | | | | info: mroonga: tm_year=-900
72389 T@3    : | | | | | | | | | | | | | | | | info: mroonga: tm_mon=0
72390 T@3    : | | | | | | | | | | | | | | | | info: mroonga: tm_mday=1
72391 T@3    : | | | | | | | | | | | | | | | | info: mroonga: tm_hour=0
72392 T@3    : | | | | | | | | | | | | | | | | info: mroonga: tm_min=0
72393 T@3    : | | | | | | | | | | | | | | | | info: mroonga: tm_sec=0
72394 T@3    : | | | | | | | | | | | | | | | <mrn::TimeConverter::grn_time_to_mysql_time 240

ちなみに TimeConverter::mysql_time_to_grn_timeのトーレスログは以下の通りになり、違いはありません。

71623 T@3    : | | | | | | | | | | | >mrn::TimeConverter::mysql_time_to_grn_time
71624 T@3    : | | | | | | | | | | | | info: mroonga: MYSQL_TIMESTAMP_DATETIME
71625 T@3    : | | | | | | | | | | | | info: mroonga: tm_year=-900
71626 T@3    : | | | | | | | | | | | | info: mroonga: tm_mon=0
71627 T@3    : | | | | | | | | | | | | info: mroonga: tm_mday=1
71628 T@3    : | | | | | | | | | | | | info: mroonga: tm_hour=0
71629 T@3    : | | | | | | | | | | | | info: mroonga: tm_min=0
71630 T@3    : | | | | | | | | | | | | info: mroonga: tm_sec=0

#53 Updated by Kenji Maruyama over 4 years ago

http://redmine.groonga.org/issues/1964#note-52 の続き、

以下どちらも

grn_time_to_mysql_time が呼ばれている関数をみると、

CentOS6 MySQL6.4の場合、

http://redmine.groonga.org/issues/1964#note-52 のSQLを実行すると、

value = "", time = -30610224000000000 という値になっています。

9744 void ha_mroonga::storage_store_field_datetime2(Field *field,
 9745                                                const char *value,
 9746                                                uint value_length)
 9747 {
 9748   MRN_DBUG_ENTER_METHOD();
 9750   long long int time = *((long long int *)value);
 9752   MYSQL_TIME mysql_datetime;
 9753   memset(&mysql_datetime, 0, sizeof(MYSQL_TIME));
 9754   mysql_datetime.time_type = MYSQL_TIMESTAMP_DATETIME;
 9755   mrn::TimeConverter time_converter;
 9756   time_converter.grn_time_to_mysql_time(time, &mysql_datetime);
 9757   field->store_time(&mysql_datetime);
 9758   DBUG_VOID_RETURN;
 9759 }

同じくFreeBSD MariaDB 10.0.8場合、

value = "", time = 0 という値になっています。

9687 void ha_mroonga::storage_store_field_datetime(Field *field,
 9688                                               const char *value,
 9689                                               uint value_length)
 9690 {
 9691   MRN_DBUG_ENTER_METHOD();
 9692   long long int time = *((long long int *)value);
 9693   MYSQL_TIME mysql_datetime;
 9694   memset(&mysql_datetime, 0, sizeof(MYSQL_TIME));
 9695   mysql_datetime.time_type = MYSQL_TIMESTAMP_DATETIME;
 9696   mrn::TimeConverter time_converter;
 9697   time_converter.grn_time_to_mysql_time(time, &mysql_datetime);
 9698 #ifdef MRN_FIELD_STORE_TIME_NEED_TYPE
 9699   Field_datetime *datetime_field = (Field_datetime *)field;
 9700   datetime_field->store_time(&mysql_datetime, mysql_datetime.time_type);
 9701 #else
 9702   field->store_time(&mysql_datetime);
 9703 #endif
 9704   DBUG_VOID_RETURN;
 9705 }

どちらも、 long long int time = *((long long int *)value); で valueは空文字列だが、timeが異なる値になっています。 型変換結果が処理系定義によるものになっていると思われる。( 参考:http://www.jpcert.or.jp/sc-rules/c-int11-c.html )

#54 Updated by Kenji Maruyama over 4 years ago

  • Status changed from 要仕様議論 to 担当者作業中

grn_time_to_mysql_time を調べていましたが、DATETIME データ挿入後のGroongaの格納データを

SELECT mroonga_command("select --table diaries");

で見てみると、

INSERT INTO diaries VALUES ('1000-01-01 00:00:00');

に対して、

FreeBSD MariaDB 10.0.8の場合

[[[1],[["_id","UInt32"],["created_at","Time"]],[1,0.0]]]

CentOS6 MySQL5.6の場合

[[[1],[["_id","UInt32"],["created_at","Time"]],[1,-30610224000.0]]]

Groongaに格納されている"Time"の値が異なるので、grn_time_to_mysql_time ではなく、mysqlからgrn_timeにするときの挙動を見てみます。

#55 Updated by Kenji Maruyama over 4 years ago

mysqlからgrn_timeにするときの挙動を見てみます。

原因は ib/mrn_time_converter.cpp のtm_to_time_gmのmktime関数のところでした。tm_year >= 1でないとだめのようです。

   37   time_t TimeConverter::tm_to_time_gm(struct tm *time) {
   38     MRN_DBUG_ENTER_METHOD();
   39     struct tm gmdate;
   40     time_t sec_t = mktime(time);

入力time どちらも以下となっていますが、

  (gdb) p *time
$3 = {
  tm_sec = 0,
  tm_min = 0,
  tm_hour = 0,
  tm_mday = 1,
  tm_mon = 0,
  tm_year = -900,
  tm_wday = 0,
  tm_yday = 0,
  tm_isdst = 0,
  tm_gmtoff = 0,
  tm_zone = 0x0
}

mktimeの返り値で

FreeBSD MariaDBは -1 (-1 if time cannot be represented as a time_t object.)

CentOS MySQL56は -30610224000

以下簡単な再現プログラムを作ってみると、FreeBSD9.1上では, sec_t = -1になりmktime失敗したことがわかり、CentOS6.4上ではsec_t = -545539328になりました。FreeBSD9.1上ではtm_yearの値は1以上なら問題ないようですが...

#include <stdlib.h>
#include <time.h>

int main(void)
{
  struct tm tdate;
  memset((void *)&tdate, '\0', sizeof(tdate));
  tdate.tm_year = -900; 

  time_t sec_t = mktime(&tdate);
  if (sec_t == -1) {
    printf("Error");
    return -1;
  }

  printf("sec_t = %d\n", sec_t);

  return 0;
}

#56 Updated by Susumu Yata over 4 years ago

Ubuntu 12.04 では tm_year を 0 以下にしても問題ありません. そこで, tm_year が 0 以下のときは小細工で対処するようにして, std::mktime() の結果と比べるプログラムを書いてみました.

以下に示すソースコードの my_mktime() が小細工版になっています. tm_year が 0 以下のときは 400 の倍数を足して 1 以上にし,後から補正するという内容です.

これだけで大丈夫かと思ったのですが,実際には tm_year < -12 のときだけ 1139 秒を引くようにしないと一致しませんでした. その理由は,現在の日本標準時が 1888 年に適用されたからのようです.

補正の方法は地域によって異なるものと考えられるため,このような方法で対処するのは難しそうです.

夏時間については, 20 世紀に入ってからのようなので問題ないはずです.

#include <cassert>
#include <ctime>
#include <iostream>
#include <random>

namespace {

std::mt19937 random;

void make_random_time(struct tm *tm) {
  tm->tm_sec = random() % 61;
  tm->tm_min = random() % 60;
  tm->tm_hour = random() % 24;
  tm->tm_mday = 1 + (random() % 31);
  tm->tm_mon = random() % 12;
  tm->tm_year = (random() % 10000) - 20000;
  tm->tm_wday = 0;
  tm->tm_yday = 0;
  tm->tm_isdst = 0;
}

std::ostream &operator<<(std::ostream &stream, const struct tm &tm) {
  stream << (tm.tm_year + 1900) << '-' << (tm.tm_mon + 1) << '-'
         << tm.tm_mday << ' ' << (tm.tm_hour + 1) << ':'
         << (tm.tm_min + 1) << ':' << (tm.tm_sec + 1);
  return stream;
}

time_t my_mktime(struct tm *tm) {
  if (tm->tm_year > 0) {
    return std::mktime(tm);
  }
  // 閏年の影響を避けるため, 400 年単位でずらしています.
  long tm_year_offset = ((-tm->tm_year / 400) + 2) * 400L;
  tm->tm_year += tm_year_offset;
  std::time_t seconds_since_epoch = std::mktime(tm);
  tm->tm_year -= tm_year_offset;
  seconds_since_epoch -= (tm_year_offset / 400) *
      ((303L * 365 * 24 * 60 * 60) + (97L * 366 * 24 * 60 * 60));
  // 日本時間については以下の補正が必要になります.
  if (tm->tm_year < -12) {
    seconds_since_epoch -= 1139;
  }
  return seconds_since_epoch;
}

}  // namespace

int main() {
  int count = 0;
  for (int i = 0; i < 1000000; ++i) {
    struct tm tm;
    make_random_time(&tm);
    struct tm tm_1 = tm;
    time_t expected = std::mktime(&tm_1);
    struct tm tm_2 = tm;
    time_t actual = my_mktime(&tm_2);
    if (actual != expected) {
      ++count;
      std::cout << "Error (" << count << '/' << (i + 1) << ")\n"
                << "Input = " << tm << '\n'
                << "Expected = " << expected
                << " (" << tm_1 << ", " << *std::localtime(&expected) << ")\n"
                << "Actual = " << actual
                << " (" << tm_2 << ", " << *std::localtime(&actual) << ")\n"
                << "Diff (Actual - Expected) = " << (actual - expected) << '\n'
                << std::endl;
    }
  }
  return 0;
}

$ clang++ -Wall -O2 -std=c++11 a.cpp
$ time ./a.out 

real    0m5.239s
user    0m3.612s
sys 0m1.612s

#57 Updated by Kenji Maruyama over 4 years ago

Ubuntu 12.04 では tm_year を 0 以下にしても問題ありません. そこで, tm_year が 0 以下のときは小細工で対処するようにして, std::mktime() の結果と比べるプログラムを書いてみました.

早い! ありがとうございます。

g++ (GCC) 4.2.1 20070831 patched [FreeBSD] とお古なので、rand()に変えて、FreeBSDで実行してみると以下になります。

std::localtime(time)のtimeが負だと2039-12-31 24:60:60になりますね...

Error (1/1)
Input = -9100-3-11 18:50:33
Expected = -1 (-9100-3-11 18:50:33, 2039-12-31 24:60:60)
Actual = -351538381767 (-9100-3-11 18:50:33, 2039-12-31 24:60:60)
Diff (Actual - Expected) = -351538381766

Error (2/2)
Input = -10321-12-6 15:25:32
Expected = -1 (-10321-12-6 15:25:32, 2039-12-31 24:60:60)
Actual = -390046096468 (-10321-12-6 15:25:32, 2039-12-31 24:60:60)
Diff (Actual - Expected) = -390046096467

Error (3/3)
Input = -10043-3-4 13:6:25
Expected = -1 (-10043-3-4 13:6:25, 2039-12-31 24:60:60)
Actual = -381297240815 (-10043-3-4 13:6:25, 2039-12-31 24:60:60)
Diff (Actual - Expected) = -381297240814

Error (4/4)
Input = -15418-5-8 2:8:55
Expected = -1 (-15418-5-8 2:8:55, 2039-12-31 24:60:60)
Actual = -550910243465 (-15418-5-8 2:8:55, 2039-12-31 24:60:60)
Diff (Actual - Expected) = -550910243464

Error (5/5)
Input = -8470-6-20 22:50:37
Expected = -1 (-8470-6-20 22:50:37, 2039-12-31 24:60:60)
Actual = -331648741763 (-8470-6-20 22:50:37, 2039-12-31 24:60:60)
Diff (Actual - Expected) = -331648741762

#58 Updated by Susumu Yata over 4 years ago

http://redmine.groonga.org/issues/1964#note-57

tm_year が 0 以下のときだけ簡単な計算で補正するというやり方では駄目でしたという報告をしておきたかっただけなのです. mktime() の方が簡単な計算で対処できていれば, localtime() の方も同じようにして対処できたのですが….

#59 Updated by Kenji Maruyama over 4 years ago

tm_year が 0 以下のときだけ簡単な計算で補正するというやり方では駄目でしたという報告をしておきたかっただけなのです. mktime() の方が簡単な計算で対処できていれば, localtime() の方も同じようにして対処できたのですが…

了解しました。myisam, innodb の方は #52 と 同じクエリで対処できているので、 mktime以外の方法で対処しているかもしれませんが見てみます。

#60 Updated by Kenji Maruyama over 4 years ago

myisam, innodb の方は #52 と 同じクエリで対処できているので、 mktime以外の方法で対処しているかもしれませんが見てみます。

mktimeを使っておらず、どちらも unsigned char型で保存している.

mroongaの場合は以下のように一回 time_converter.mysql_time_to_grn_time変換(この中でmktimeしている)して、GRN_TIME_SETしている。

頑張ってmk_timeをラップするか、time_converter.mysql_time_to_grn_time変換しないようにするかという所でしょうか。

  long long int time = time_converter.mysql_time_to_grn_time(&mysql_time,
                                                             &truncated);
  if (truncated) {
    field->set_warning(Sql_condition::WARN_LEVEL_WARN,
                       WARN_DATA_TRUNCATED, 1);
  }
  grn_obj_reinit(ctx, buf, GRN_DB_TIME, 0);
  GRN_TIME_SET(ctx, buf, time);

以下参考までに挿入時のそれぞれのバックトレース

INSERT INTO diaries VALUES ('1000-01-01 00:00:00');

myisam

#0  mi_write (info=0x822017108, record=0x8220f39a0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/storage/myisam/mi_write.c:237
#1  0x0000000000ab2859 in ha_myisam::write_row (this=0x822391720,
    buf=0x8220f39a0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/storage/myisam/ha_myisam.cc:860
#2  0x000000000082509a in handler::ha_write_row (this=0x822391720,
    buf=0x8220f39a0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/sql/handler.cc:5879
#3  0x0000000000609052 in write_record (thd=0x823380808, table=0x8223b4408,
    info=0x7ffffcd51830) at /home/vagrant/maria/mroonga/sql/sql_insert.cc:1876
#4  0x000000000060e233 in mysql_insert (thd=0x823380808, table_list=0x822636420,
    fields=@0x8233850b0, values_list=@0x823385110, update_fields=@0x8233850f0,
    update_values=@0x8233850d0, duplic=DUP_ERROR, ignore=false)
    at /home/vagrant/maria/mroonga/sql/sql_insert.cc:1001
#5  0x000000000062ab88 in mysql_execute_command (thd=0x823380808)
    at /home/vagrant/maria/mroonga/sql/sql_parse.cc:3468
#6  0x00000000006304dd in mysql_parse (thd=0x823380808,
    rawbuf=0x82262a0e0 "INSERT INTO diaries VALUES ('1000-01-01 00:00:00')", length=50,
    parser_state=0x7ffffcd52710) at /home/vagrant/maria/mroonga/sql/sql_parse.cc:6447
#7  0x0000000000631009 in dispatch_command (command=COM_QUERY, thd=0x823380808,
    packet=0x80395a009 "INSERT INTO diaries VALUES ('1000-01-01 00:00:00')",
    packet_length=50) at /home/vagrant/maria/mroonga/sql/sql_parse.cc:1308
#8  0x0000000000632872 in do_command (thd=0x823380808)
    at /home/vagrant/maria/mroonga/sql/sql_parse.cc:1005
#9  0x0000000000741555 in do_handle_one_connection (thd_arg=0x823380808)
    at /home/vagrant/maria/mroonga/sql/sql_connect.cc:1379
#10 0x000000000074164d in handle_one_connection (arg=0x823380808)
    at /home/vagrant/maria/mroonga/sql/sql_connect.cc:1293
#11 0x0000000000e4a649 in pfs_spawn_thread (arg=0x824d9c378)
    at /home/vagrant/maria/mroonga/storage/perfschema/pfs.cc:1853
#12 0x00000008018340a4 in pthread_getprio () from /lib/libthr.so.3

innodb

#0  row_mysql_store_col_in_innobase_format (dfield=0x825990418, buf=0x8259903d1 "",
    row_format_col=1, mysql_data=0x8220f39a5 "\030\t", col_len=8, comp=1)
    at /home/vagrant/maria/mroonga/storage/innobase/row/row0mysql.cc:391
#1  0x0000000000c060d8 in row_mysql_convert_row_to_innobase (row=0x8259903e0,
    prebuilt=0x82598fe78, mysql_rec=0x8220f39a0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/storage/innobase/row/row0mysql.cc:561
#2  0x0000000000c0637a in row_insert_for_mysql (
    mysql_rec=0x8220f39a0 "\375@\303wT\030\t", prebuilt=0x82598fe78)
    at /home/vagrant/maria/mroonga/storage/innobase/row/row0mysql.cc:1293
#3  0x0000000000b32b3c in ha_innobase::write_row (this=0x825457020,
    record=0x8220f39a0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/storage/innobase/handler/ha_innodb.cc:6940
#4  0x000000000082509a in handler::ha_write_row (this=0x825457020,
    buf=0x8220f39a0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/sql/handler.cc:5879
#5  0x0000000000609052 in write_record (thd=0x822c59808, table=0x8223b4408,
    info=0x7ffffcd51830) at /home/vagrant/maria/mroonga/sql/sql_insert.cc:1876
#6  0x000000000060e233 in mysql_insert (thd=0x822c59808, table_list=0x822635420,
    fields=@0x822c5e0b0, values_list=@0x822c5e110, update_fields=@0x822c5e0f0,
    update_values=@0x822c5e0d0, duplic=DUP_ERROR, ignore=false)
    at /home/vagrant/maria/mroonga/sql/sql_insert.cc:1001
#7  0x000000000062ab88 in mysql_execute_command (thd=0x822c59808)
    at /home/vagrant/maria/mroonga/sql/sql_parse.cc:3468
#8  0x00000000006304dd in mysql_parse (thd=0x822c59808,
    rawbuf=0x8224631a0 "INSERT INTO diaries VALUES ('1000-01-01 00:00:00')", length=50,
    parser_state=0x7ffffcd52710) at /home/vagrant/maria/mroonga/sql/sql_parse.cc:6447
#9  0x0000000000631009 in dispatch_command (command=COM_QUERY, thd=0x822c59808,
    packet=0x80395a009 "INSERT INTO diaries VALUES ('1000-01-01 00:00:00')",
    packet_length=50) at /home/vagrant/maria/mroonga/sql/sql_parse.cc:1308
#10 0x0000000000632872 in do_command (thd=0x822c59808)
    at /home/vagrant/maria/mroonga/sql/sql_parse.cc:1005
#11 0x0000000000741555 in do_handle_one_connection (thd_arg=0x822c59808)
    at /home/vagrant/maria/mroonga/sql/sql_connect.cc:1379
#12 0x000000000074164d in handle_one_connection (arg=0x822c59808)
    at /home/vagrant/maria/mroonga/sql/sql_connect.cc:1293
#13 0x0000000000e4a649 in pfs_spawn_thread (arg=0x824d9c2e8)
    at /home/vagrant/maria/mroonga/storage/perfschema/pfs.cc:1853
#14 0x00000008018340a4 in pthread_getprio () from /lib/libthr.so.3

mroonga


(gdb) bt
#0  ha_mroonga::generic_store_bulk_datetime (this=0x825857020, field=0x8220e9920, buf=0x7ffffcd50fa0)
    at /home/vagrant/maria/mroonga/storage/mroonga/ha_mroonga.cpp:9229
#1  0x0000000823847632 in ha_mroonga::generic_store_bulk (this=0x825857020, field=0x8220e9920, buf=0x7ffffcd50fa0)
    at /home/vagrant/maria/mroonga/storage/mroonga/ha_mroonga.cpp:9417
#2  0x0000000823854f84 in ha_mroonga::storage_write_row (this=0x825857020, buf=0x8220f39e0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/storage/mroonga/ha_mroonga.cpp:5275
#3  0x00000008238555f9 in ha_mroonga::write_row (this=0x825857020, buf=0x8220f39e0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/storage/mroonga/ha_mroonga.cpp:5534
#4  0x000000000082509a in handler::ha_write_row (this=0x825857020, buf=0x8220f39e0 "\375@\303wT\030\t")
    at /home/vagrant/maria/mroonga/sql/handler.cc:5879
#5  0x0000000000609052 in write_record (thd=0x823380808, table=0x8223b4e08, info=0x7ffffcd51830)
    at /home/vagrant/maria/mroonga/sql/sql_insert.cc:1876
#6  0x000000000060e233 in mysql_insert (thd=0x823380808, table_list=0x822636420, fields=@0x8233850b0,
    values_list=@0x823385110, update_fields=@0x8233850f0, update_values=@0x8233850d0, duplic=DUP_ERROR, ignore=false)
    at /home/vagrant/maria/mroonga/sql/sql_insert.cc:1001
#7  0x000000000062ab88 in mysql_execute_command (thd=0x823380808) at /home/vagrant/maria/mroonga/sql/sql_parse.cc:3468
#8  0x00000000006304dd in mysql_parse (thd=0x823380808,
    rawbuf=0x82262a0e0 "INSERT INTO diaries \n       VALUES ('1000-01-01 00:00:00')", length=58, parser_state=0x7ffffcd52710)
    at /home/vagrant/maria/mroonga/sql/sql_parse.cc:6447
#9  0x0000000000631009 in dispatch_command (command=COM_QUERY, thd=0x823380808,
    packet=0x80395a009 "INSERT INTO diaries \n       VALUES ('1000-01-01 00:00:00')", packet_length=58)
    at /home/vagrant/maria/mroonga/sql/sql_parse.cc:1308
#10 0x0000000000632872 in do_command (thd=0x823380808) at /home/vagrant/maria/mroonga/sql/sql_parse.cc:1005
#11 0x0000000000741555 in do_handle_one_connection (thd_arg=0x823380808)
    at /home/vagrant/maria/mroonga/sql/sql_connect.cc:1379
#12 0x000000000074164d in handle_one_connection (arg=0x823380808) at /home/vagrant/maria/mroonga/sql/sql_connect.cc:1293
#13 0x0000000000e4a649 in pfs_spawn_thread (arg=0x824f38348) at /home/vagrant/maria/mroonga/storage/perfschema/pfs.cc:1853
#14 0x00000008018340a4 in pthread_getprio () from /lib/libthr.so.3
#15 0x0000000000000000 in ?? ()

#61 Updated by Kenji Maruyama over 4 years ago

  • Status changed from 担当者作業中 to 要仕様議論

#62 Updated by Kouhei Sutou over 4 years ago

FreeBSDの時間のやつは子チケットにしてもらえませんか!?

Also available in: Atom PDF