#その後、u_longやu_int、NSIGなどの、XPG互換で省略されてしまう諸々を自前で再定義してみたんですが、struct ifreqが未定義という所までいってやめました。_XOPEN_SOURCEを定義するなら、XPG/POSIX系のAPIを使えって事なんでしょうが、ちょっと修正の範囲が広くなり過ぎてしまって。_XOPEN_SOURCEを使うよりは、struct msghdrのmsg_accrightsを使うようにした方が影響が少なくていいのかもしれません。
#この辺は結構みんな難儀しているようで、PostfixやRubyなどにも対応コードがあるようです。いずれにせよ、修正の影響が大きそうでしたら、どうぞ先延ばしにして下さい。丁寧に対応して頂いてありがとうございます。
#仕事場が停電したのでtwitterブリッジが止まってました。
#こちらの環境でも、ext/threads/test.scmの2箇所をコメントアウトしたら現象が出なくなりました。
#make checkの結果もすべてpassedです。
#複数のバージョンの Gauche をインストールしている人って、どういうディレクトリレイアウトでインストールしているんでしょうか? trunk を追いかけている人は少なくとも最新の release 版も入っているわけですよね?
#trunkで生活してますね
#Releaseはビルドしたディレクトリを残しておいて、必要な時make installしますかね
#あとは、常套手段ですが、/usr/local/gauche-0.8.14 を prefix にしてリリースを入れとくとか
#なるほどー。基本は上書きですか。
#ぼくはさいきんは prefix=$HOME/local とかにして、後で消したいときとかは別のディレクトリを指定したりしてました。
#--- a/doc/modgauche.texi
+++ b/doc/modgauche.texi
@@ -4048,7 +4048,7 @@ the log drain temporary.
引数無しで呼ばれると、@code{log-format}が使う、
現在のデフォルトのログの行き先が返されます。
まだデフォルトのログの行き先が@code{log-open}で指定されていない場合は
-@code{#f}が帰ります。
+@code{#f}が返ります。
新たな@code{<log-drain>}オブジェクトか@code{#f}を引数にして呼び出すと、
デフォルトのログの行き先がそれに変更されます。
@@ -5824,7 +5824,7 @@ Looks up a host named @var{name}.
If found, returns a @code{<sys-hostent>} object.
Otherwise, returns @code{#f}.
@c JP
-@var{name}という名まえのホストを探し、見つかれば、@code{<sys-hostent>}
+@var{name}という名前のホストを探し、見つかれば、@code{<sys-hostent>}
オブジェクトを返します。見つからなければ、@code{#f} を返します。
@c COMMON
@example
@@ -5912,7 +5912,7 @@ Otherwise, @code{#f} is returned.
ネットワークサービスデータベースをサービス名 @var{name} および
プロトコル @var{proto} で検索します。@var{name} および @var{proto}
は文字列でなければなりません。サービスが見つかれば、@code{<sys-servent>}
-のインスタンスが返します。見つからなければ、@code{#f} を返します。
+のインスタンスを返します。見つからなければ、@code{#f} を返します。
@c COMMON
@example
(let ((serv (sys-getservbyname "http" "tcp")))
@@ -5936,7 +5936,7 @@ Otherwise, @code{#f} is returned.
プロトコル @var{proto} で検索します。@var{port} は正確な整数でなければ
なりません。また、@var{proto} は文字列でなければなりません。
サービスが見つかれば、@code{<sys-servent>}
-のインスタンスが返します。見つからなければ、@code{#f} を返します。
+のインスタンスを返します。見つからなければ、@code{#f} を返します。
@c COMMON
@example
(let ((serv (sys-getservbyport 6000 "tcp")))
#細かいですがtypo修正です。
#基本は上書きですねぇ
#Kahuaの開発環境では、リリースとtrunkを両方入れてましたね
#PATHで切り替えてた
#>k_tsj fixed. mahalo.
#cancellationとgcの問題だけど、開発版にあてられたBoehm氏のパッチをバックポートしただけでは解決しないなあ。別の要因か?
#pthread_cancelした場合、Gaucheで設定してるcleanup procは呼ばれるのにGCが設定してるcleanup proc (その中でGC内でのスレッドの登録を消している) が呼ばれないことが判明。ゾンビ状態で生きている?
#ゾンビ状態というわけではない。DEBUG_THREADSをdefineして追ってみると、次に作成したスレッドがcancelしたスレッドと同じアドレスになってるから、libc的にはcancelしたスレッドは既に無いものとされている。ただ、GCのcleanup procが呼ばれてないためにそのスレッドアドレスがテーブル内で重複登録される。
#cleanup procが全く呼ばれないならそれはそれでlibcのバグって気もするが、ひとつだけ呼ばれてるってのが解せないなあ。
#ダミーのcleanup procを色々突っ込んでみたところ、Gauche側のスレッドルーチンで仕込んだcleanup procは常に呼ばれる(元々のcleanup procの前でも後でも)が、GC側のスレッドルーチンで仕込んだcleanup procはpthread_cancelでもpthread_exitでも呼ばれないことがわかった。GC側のスレッドルーチンからGauche側へは関数ポインタ呼び出しをしてるだけなのになあ。
#cleanup procが呼ばれない、という現象はi386特有であることを確認。x86_64ではちゃんと呼ばれる。したがって問題が出ることはない。
#Gauche抜きで試しても再現した。glibcも怪しいけどとりあえずgcの方に質問メール投げてみた。
#netbsd-current では、どうやら binutils 2.19 に以降した port では gauche 動きません。 OS 側 (libc) の対応と gc/ の変更が必要。
#むー、gcが対応してないって問題ですか?
#とりあえずthreadsでハングする問題はgcの方に重複登録チェックを入れて回避できた模様。
##gc 側では dynamic load されたライブラリをスキャンしてgc root を探すのを (既にある)dl_iterate_phdr を使う方に切り替えればいいみたいなんですが、dl_iterate_phdr 自体がnetbsdにないんです。
#boehm gcのmlを検索してみたけどまだレポートされてないようですね
#Gaucheno
#freebsd 7 用の同様の対応は gc 7.2alpha2 には入っているようです。
#Gaucheのextensionだけの対応でいいなら、extensionは明示的に自分を登録するので、data領域とbss領域の始点と終点に特定のシンボルがあれば対応できます。
#例えばCygwinはそれぞれ_data_start__, _data_end__, _bss_start__, _bss_end__というシンボルが定義されてるのでそれを使ってます (src/gauche/extend.h)
##あーでもelfだとdataやbssが固まってるとは限らないのかな。
#libgauche.so のもさがしてくれないので。
#ああ、dlopen()されたやつだけじゃなくてld.soがやるやるもダメなんですか。
#s/やるやるも/やるのも/
#そのFreeBSDのやつは流用できそうですか?
#そうみたいです。GC_add_root_inner() が一回しか呼ばれていないことは確認しました。
#FreeBSD のを流用するには dl_iterate_phdr() が必要なんですが、それがない、と。
#むー、今まではどうしてたんでしょ。
#GC_init_netbsd_elfではグローバル変数アドレスをもとにGC_find_limitを呼んでますね。これがうまく動かなくなったということ?
#GC_FirstDLOpenedLinkMapのほうです。
#従来もそっちでlibgauche.soのデータエリアが登録されていたんでしょうか? GC_FirstDLOpenedLinkMapはGC_register_dynamic_librariesで使われますが、これってGC初期化後に追加されたdynamic libraryをチェックするのが目的ですよね。GC初期化時には既にlibgauche.soはロードされてて、GC_init_netbsd_elfのGC_data_startはlibgauche.so中にあるのでそこで登録されても良さそうな気がするけど…
#まあ、たとえlibgauche.soがクリアできたとしてもGC_register_dynamic_librariesが動かなければ使えないですね。
#あれ、じゃあまた違うのかなあ。
#新しいbinutilsで動かなくなったのは、_DYNAMICが定義されない、もしくは構造が変わった、とかかな?
#少なくとも GC_data_start と GC_stackbottom は正しそうな値がセットされていました。
#_DYNAMIC 自体はあります。
#netbsd の libexec/ld.elf_so/rtld.c をみると dlinfo() っていう関数があって、これで struct link_map * がとれるっぽい。これでなんとかなるかな?
#% diff -u gc/dyn_load.c.orig gc/dyn_load.c
--- gc/dyn_load.c.orig 2009-11-04 17:36:21.000000000 +0900
+++ gc/dyn_load.c 2009-11-04 17:42:07.000000000 +0900
@@ -78,6 +78,7 @@
#endif
#if defined(NETBSD)
+# include <dlfcn.h>
# include <machine/elf_machdep.h>
# define ELFSIZE ARCH_ELFSIZE
#endif
@@ -499,6 +500,7 @@
return(0);
}
if( cachedResult == 0 ) {
+#if 0
int tag;
for( dp = _DYNAMIC; (tag = dp->d_tag) != 0; dp++ ) {
if( tag == DT_DEBUG ) {
@@ -508,6 +510,15 @@
break;
}
}
+#else
+ struct link_map *lm = NULL;
+ int rv = dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, &lm);
+ if (rv != 0)
+ return (0);
+ if (lm == NULL)
+ return (0);
+ cachedResult = lm;
+#endif
}
return cachedResult;
}
#これで 0.8.14 の build はできた。今までは src/gosh -ftest がおちるので bulid できていなかった。