rubyでやるようになって、dlが必ずエラーになるのでうんざりして、結局libffi+fiddleを使うようにした。ABI)、ではなぜlibffiを正式に入れ込まないかと言えば、MSWin32サポートが心もとない(ということだったと思う)。今は、dlを残しておくけど、必要ならばlibffiをどうにかしてfiddleを使えということらしい。fiddleがあればdl(の.rbのほう)はdl.soではなくfiddleを使う。いやだが背に腹は代えられないのでmsysを導入する。bashが動くのは良いけれど、さっそくvcvars_x64.batとかが動かない。ディレクトリセパレータ問題だよ。見たところ、bash起動前に設定してあるPATH、LIB、INCLUDEについては、ディレクトリセパレータ変換は自動的に行ってくれるようだが、後付けでvcvars*を実行するようなことには耐えてくれないようなので、面倒なのでいい加減なシェルを作って、.コマンドで読み込ませることにする。CommandPromptType=Nativeこれで、x64のVC++が動けるようになった。https://...で取ってくる(と書いておけば、本当はcloneではなくxxxを使えみたいなのがあれば指摘してもらえるだろう)。READMEを読むとVC++(というよりもcl)をサポートしているから、CCにmsvcc.shを指定しろとか書いてある。やったらml64でエラーになる。不思議に思ってみると、.386とかいうディレクティブがいきなり書いてあってそれはエラーになるだろう。いうか、レジスタもeaxとかばかりだし。そこでターゲットを指定しなければならないのだとわかり、configureを読みながら次のように実行。--prefix=/c/Users/arton/64ところが、--prefixは後で衝撃の事実に見舞われることになる。この時点では問題なし。libffiを見たら、ターゲットのことは書いてあった。libffiはfix_src_pathは修正してあるのであった。installしたのだが、fiddleのビルドに失敗する。ライブラリの形式が無効です。ライブラリは無視されます。えー、とdumpbinをかけると確かにエラーになる。dllがなくてlibだけしか作られていないし。見ていくと、x86_64-w64-mingw32/src/.libsの下に作成されたlibffi.libとインストールされたlibffi.libで微妙にサイズが異なる。src/.libsのほうはdumpbinがちゃんと読み込んで処理できる。ああ、「生成されるlibtoolファイルには余計なことをするバグがある」ってのはこれのことか、と思いながら、.libsのほうのlibffi.libでインストールされたlibffi.libを上書きする。再度、.ext/fiddleの中を消してやって、nmakeすると、今度はfiddle.soができた。TESTS="dl"がいずれも通ることを確認。追記:結局DLLは生成されていないが、ffiとリンクしたいのはfiddleだけなのだからスタティックライブラリで良いことに気付いたので、そこは無視。variable%%%"というようなマジックコメントを埋め込んでいて、インストールするときはgrepでそれを検出したら.libs/以下のやつをインストールする、みたいなことをしているのですが、.exeとかバイナリのやつはgrepがバイナリだなぁと判断してうまく検出できなったりします。