From: Aaron Patterson Date: 2010-02-28T09:01:37+09:00 Subject: [ruby-dev:40522] Re: [ruby-cvs:33760] Ruby:r26545 (trunk): Wed Feb 3 10:12:09 2010 Aaron Patterson 2010/2/26 NARUSE, Yui : > アーロン宛です。 > > 成瀬です。 > > (2010/02/27 12:41), U.Nakamura wrote: >> In message "[ruby-dev:40511] Re: [ruby-cvs:33760] Ruby:r26545 (trunk): Wed Feb 3 10:12:09 2010 Aaron Patterson " >> on Feb.27,2010 10:01:24, wrote: >>> 2010/2/25 NARUSE, Yui : >>>> その後 Aaron さんから特に反応がないので ext/dl 下を巻き戻しました。 >>>> 再マージの際には mswin32/mswin64 でビルド出来る事が期待されます。 >>> >>> お手数ですが、メイルの先頭に、「アーロン宛」と記述して下さると、大変助かります。 >>> 日本語で返事を書くのは私にとってかなり時間がかかるので、頻繁に返事をしない事を先にお詫びしておきます。 >>> 皆さんと同じなように、私も沢山のメイルを毎日扱っていますので、今後見落としがない為にも宜しくお願いします。 > > RubyInstaller/sqlite3-ruby の Luis Lavena さんも興味を持っているようですから、 > ruby-core に投げ直してもいいかなと思っています。 > >>> ところで、実際にlibffiをMSVC++でコンパイルされた方はおりますか？Luis Lavena (the One-Click >>> installer maintainer)　によると、libffiはMSVC++でコンパイルするそうです。 >>> >>> http://twitter.com/luislavena/status/9650556934 >> >> 現在リリースされているバージョン(3.0.9)のlibffiはVCをまったく >> サポートしていません。 >> >> >> 以上で結論ということで話を打ち切ってもいいんですが、私もDLの >> libffi化を完全に否定してるわけでもないので、もうちょっと時間 >> をつぎ込んで調べてみると、gitリポジトリでは今年の1月16日頃に >> VCサポートっぽい変更が加えられています。 >> # ちなみに、CC(およびCPP)、LDのみcl.exeとlink.exeを使い、後は >> # shとかmakeとかいった関連ツールは全てcygwinあたりで用意する >> # ことが前提のようです。 >> >> というわけで、取ってきて試してみましたが、 >> >> * VC6ではサポートされていないコマンドラインオプションを使用 >> しようとするのでエラーが出て一切先に進まない >> >> * VC8でもパス区切りとしての\の扱いに問題があるようでやっぱ >> り先に進まない > > VC9で試しましたが、これはパス区切りを / にしないといけないらしいので、 > configure 後に 生成された libtool 中の > fix_srcfile_path の cygpath -w を cygpath -u に変えたら、 > ここは通過しました。 > >> * というわけなので、x64に関しては調べる気も起きない >> >> という状況で、なんか条件をそろえて頑張ってビルドツール類をデ >> バッグすれば先に進めるのかもしれないけれど、現時点でこれが「 >> コンパイルできる」という状態であると言い切るのは無理がある、 >> という感じです。 > > わたしは MSYS の sh.exe とかを cmd.exe から使いました。 > で、結局後述のようなエラーで諦めました。 > >> しかし、別にlibffi自体をVCでコンパイルできる必要なんか全然な >> くて、Windowsで正しく動くlibffiのバイナリがありさえすれば、あ >> とはrubyの構築時に必要なファイル群(ヘッダとライブラリファイル) >> さえ用意可能なら問題ないと言えないこともありません。 >> libffiを動的リンクするならmingw版libffiのDLLからインポートラ >> イブラリを作りさえすればいいような気もするんですが、誰かそっ >> ちの方向でアプローチしてたりしませんかね? >> たぶん現状のlibffiのVCサポートをhack & debugした上でlibffi側 >> にアプローチするより、こっちの方が遥かに楽だろうと思います。 > > アプローチしました。 > MSYS からやはり git HEAD をビルドしたところ、libffi.dll.a ができたので、 > ffi.lib にリネームして、ffi.h と ffitarget.h と合わせて ext/dl 直下に置いてみたら、 > とりあえず extconf.rb は突破できるようになりました。 > > 後続のために以下の URL にこの 3 ファイルを ZIP したものを置いておきました。 > http://nalsh.jp/patches/libffi-head-20100227.zip > > で、これを使うと、Makefile は作れるのですが、以下のようなエラーで止まりました。 > sys/mman.h は POSIX 依存のヘッダらしいです。 > なので、これを直さない限り ext/dl with libffi は MSVC++ ではビルド出来ないはずです。 > おそらく、Luis ができたというのは mingw32 での話じゃないかなぁ。 > > compiling dl > ..\..\miniruby.exe -I'../..' -I'../.././lib' -I'../../.ext/i386-mswin32_ > 90' -I'../../.ext/common' -I./- -I'../.././ext' -rpurelib.rb -e "puts 'EXPORTS', > 'Init_dl'" > dl-i386-mswin32_90.def > cl -nologo -I. -I../../.ext/include/i386-mswin32_90 -I../.././include -I > ../.././ext/dl -MD -Zi -W2 -wd4996 -O2sy- -Zm600 -DRUBY_EXTCONF_H=\"extconf.h\" > -I/usr/include -Focfunc.obj -c -Tccfunc.c > cfunc.c > cl -nologo -I. -I../../.ext/include/i386-mswin32_90 -I../.././include -I > ../.././ext/dl -MD -Zi -W2 -wd4996 -O2sy- -Zm600 -DRUBY_EXTCONF_H=\"extconf.h\" > -I/usr/include -Foclosure.obj -c -Tcclosure.c > closure.c > closure.c(7) : fatal error C1083: include ファイルを開けません。'sys/mman.h': No > such file or directory 古いlibffiを使う時にのみ 'sys/mman.h' が必要なだけで、新しい libffi には不必要です。 Visual Studioをま だ、入手していないので、良かったら、私のフォークを（sys/mman.hを使用としない）コンパイルして貰えませんか？ 私のフォークのリンクは下記の通りです。 https://github.com/tenderlove/ruby/tree/ffi この変更で現在のコンパイルエラーを解決出来ると思います。 https://github.com/tenderlove/ruby/commit/d10980da20ae210ceed30c7829a07d0d8275c7ec 私自身でも、Visual Studioを入手次第、テストしてみるつもりです。 宜しくお願いします。 -- Aaron Patterson http://tenderlovemaking.com/