#Windows (msys2) 上でも libdl の dlopen が有ればそれを使うようになっているのは意図的なものですか? 私の環境でビルドするとなんだか DLL の余計な依存関係が出来てるっぽいなーと気にかかっていたのですが、 libdl.dll 経由だということがわかったので。
#いや、mingwではdlopen使わないのでチェックそのものが不要ですね。
#diff --git a/configure.ac b/configure.ac
index 2b3bc3d..d7bd5f3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -591,8 +591,15 @@ case "$host" in
esac
dnl Checks if dlopen exists, and if it's in libc or libdl.
-AC_SEARCH_LIBS(dlopen, dl, AC_DEFINE(HAVE_DLOPEN,1,[Define if the system has dlopen()]))
-
+dnl On MinGW, we call LoadLibrary so we don't need dlopen (see dl_win.c)
+case "$host" in
+ *mingw*)
+ : ;;
+ *)
+ AC_SEARCH_LIBS(dlopen, dl, AC_DEFINE(HAVE_DLOPEN,1,[Define if the system has dlopen()]))
+ ;;
+esac
+
dnl Checks for sched_yield.
AC_SEARCH_LIBS(sched_yield, rt, AC_DEFINE(HAVE_SCHED_YIELD,1,[Define if uses librt]))
#こんなかんじ?
#試してみます。
#はい。 それで libdl.dll への依存は消えました。
#それと、 clock_gettime などのために pthread (libwinpthread-1.dll) への依存もあるようです。
#./configure の前に LDFLAGS="-no-pthread" を付けて回避しているのですが、
#./configure の中で分岐した方が良いかもしれないですね。
#そうか、スレッドをwinpthread経由にするか直接win32 apiを叩くかについては迷ってた時期があってwinpthread.dllへの依存は許容してたんですが、今はGauche本体はwin32 apiを直接叩いてるからlibgcがokなら要らないですね。てかconfigure内でpthreadとmingwの組み合わせは拒否してら。
#clock_gettimeはlibrtにあるかどうかをチェックしてるんだけど、それをするとpthreadへの依存が入っちゃうってこと? これは実機で試してみた方がいいかな
#AC_CHECK_FUNCS でも clock_gettime をチェックしているようですね。
#configure.ac の書き方をよくわかってないんですけど、
#これで librt 内だけがチェックされるんですか?
#CHECK_LIBはlibrtがリンク可能かどうかを調べて、可能ならLIBSに-lrtを、config.hにHAVE_LIBRTを足します。ここでのclock_gettimeは単にlibrtをリンクしてみる時に使われるだけです。(そのライブラリ内の関数を呼び出すダミーのコードをコンパイル・リンクする)。AC_CHECK_FUNCSは列挙された関数それぞれを呼び出すコードがコンパイル・リンク可能かどうかを調べて、可能なら HAVE_関数名 を定義します。
#clock_gettime は libwinpthread-1.dll 内にも有って、私の環境の gcc は specs を見ると -lpthread が付くのがデフォなので、それだと -lrt に関係なく clock_gettime が有ると判断されて pthread に依存が出来ることになりますね
#なるほどデフォでついちゃうんですね。-no-pthreadをつけた場合clock_gettimeは使えなくなるとしても、winpthread依存がないほうがうれしいかな。ずっと昔、bdwgcの方でwinpthreadに依存してる何かがあったような覚えがなんとなくあるんですが、-no-pthreadつけてもスレッドの使用に問題はありませんか?
#依存の調査を始めたのが機能なので、依存をなくした奴を使いこんではいません。
#とりあえず make check をやってみます。
#スレッド系に問題があったとしたら再現性とかが微妙だったりしがちなので、あまりあてにならないかもしれませんが……
#Testing threads ... passed.