えーと、まだFreeBSD 7.0-RELEASEはリリースされていませんが、これは現時点での、7-STABLEでのお話。
FreeBSD 6.2-STABLEから、FreeBSD 7-STABLEに、make buildworld ...でアップグレードしたマシンで、FreeBSD6のころまで使っていた古いバイナリを実行したとき、
Fatal error 'Cannot allocate red zone for initial thread' at line 382 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12)
というエラーメッセージが大量に表示されて、最後にsegmentation faultとか出ておしまい、ということがあります。
今のFreeBSDには、libpthreadとlibthrという2つのスレッドライブラリがあって、
'Cannot allocate red zone for initial thread'
というエラーは、この2つを混ぜて使ったときに発生するらしいです。
混ぜるな危険！
pthreadは、昔からある方で、libthrは、マルチプロセッサ環境のときにパフォーマンスがでるように改良されているみたいです。そのため、最近は、libthrが使われるみたいです。
昔のバイナリはpthreadとリンクされるのですが、FreeBSD7上で実行しようとしたとき、依存する共有ライブラリの何かがlibthrを要求するようになってしまうみたいです。
このエラーがでたとき、定番の修正方法というのは、
portupgrade -fでビルドしなおせ
とのことです。個人的な経験では、portupgradeだとまれに失敗することがあるので、そのときは、pkg_deleteしてmake installすれとか、FORCE_PKG_REGISTERをセットして上書きするなどすれば、だいたい大丈夫でした。
☆
まあ、ソースからコンパイルできるものは、portupgradeで再ビルドでいいのですが、できないもの、たとえば、
- ソースがないとか、
- 新しいコンパイラ（GCC 4.2）ではコンパイルできないとか、
- バイナリで提供されたソフトウェア、
- 市販パッケージソフト
などでは、コンパイルしなおすことはできません。
そういうときは、どうすりゃいいんだい？
/etc/libmap.conf でライブラリのマッピングルールを指定する
これで、なんとかなるみたいです。
☆
ちなみに、私が気がついた不具合としては、MH (/usr/ports/japanese/mh)と、オムロンソフトの市販ソフト「Wnn7 Personal」のjserver、GridEngine (SGE, /usr/ports/sysutils/sge)が動かなくなりました。
MHは、portsだからportupgrade -fすればいいと思ったのですが
# portupgrade -f mh-6.8.4.j3.05
** Port marked as IGNORE: japanese/mh:
is marked as broken: Does not compile with GCC 4.2といわれました。そういえば、BROKENのままだったために、ja-mhが削除される寸前までいってましたね。直してくれた方には、感謝。
Wnn7は、もともと FreeBSD5用だったりするんですよね。FreeBSD6では動いてたのですが、FreeBSD7になったら、私の環境ではlibthrホゲホゲ～エラーで動かなくなってしまいました。
GridEngineは、FreeBSD6なホストと同一バイナリを使っているため、FreeBSD7でビルドしなおすこともできません。
☆
■ 準備
旧バージョンのバイナリを実行するので、ports/misc/compat6x や ports/misc/compat5x をインストールしておきます。
またmake buildworld && make installworld しただけでは、/libや/usr/libに、旧バージョンのライブラリがそのまま残っていて、あれこれ問題を起こします。旧バージョンのライブラリは、/lib、/usr/libなどから、きれいさっぱり、削除しておく必要があります。
(2007/12/5 追記) 実は先日知ったことなんですが、make installworldのあと、make delete-old、make delete-old-libsなどで、古いファイルを削除できるようになってます。昔は、こんな便利な機能はなかったです。
詳しいことは/usr/src/Makefile内のコメントを参照。
http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/Makefile?rev=1.341.2.1&content-type=text/x-cvsweb-markup
■ いったい、どこからlibthrが呼び出されるのか？
手ごろなところで、MHのscanコマンドで調査。
% ldd /usr/local/bin/scan
/usr/local/bin/scan:
libmh.so.3 => /usr/local/lib/libmh.so.3 (0x28084000)
libncurses.so.5 => /usr/local/lib/compat/libncurses.so.5 (0x280a4000)
libc.so.5 => /usr/local/lib/compat/libc.so.5 (0x280e3000)
う～ん、libc.so.5をリンクしてるってことは、これ、FreeBSD5なバイナリだったんですね・・・
lddではlibthrがリンクされていると見えなかったので、ktrace scanで実行してから、kdumpで眺めてみました。
# kdump | grep NAMI
～～略～～
34515 scan NAMI "/usr/local/lib/gcc-4.2.3/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/graphviz/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/kde3/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/mplayer/vidix/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/mysql/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/nss/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/pth/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/wine/nss_dns.so.1"
34515 scan NAMI "/lib/nss_dns.so.1"
34515 scan NAMI "/usr/lib/nss_dns.so.1"
34515 scan NAMI "/usr/local/lib/nss_ldap.so.1"
34515 scan NAMI "/usr/local/lib/nss_ldap.so.1"
34515 scan NAMI "/usr/local/lib/libldap-2.3.so.2"
34515 scan NAMI "/usr/local/lib/libldap-2.3.so.2"
34515 scan NAMI "/usr/local/lib/liblber-2.3.so.2"
34515 scan NAMI "/usr/local/lib/liblber-2.3.so.2"
34515 scan NAMI "/usr/local/lib/libc.so.7"
34515 scan NAMI "/lib/libc.so.7"
34515 scan NAMI "/lib/libc.so.7"
34515 scan NAMI "/usr/local/lib/libsasl2.so.2"
34515 scan NAMI "/usr/local/lib/libsasl2.so.2"
34515 scan NAMI "/usr/local/lib/libssl.so.5"
34515 scan NAMI "/usr/local/lib/libssl.so.5"
34515 scan NAMI "/usr/local/lib/libcrypto.so.5"
34515 scan NAMI "/usr/local/lib/libcrypto.so.5"
34515 scan NAMI "/usr/local/lib/libthr.so.3"
34515 scan NAMI "/lib/libthr.so.3"
34515 scan NAMI "/lib/libthr.so.3"
この結果から適当に目星をつけて、
# ldd /usr/local/lib/nss_ldap.so.1
/usr/local/lib/nss_ldap.so.1:
libldap-2.3.so.2 => /usr/local/lib/libldap-2.3.so.2 (0x281a1000)
liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x281d8000)
libc.so.7 => /lib/libc.so.7 (0x28088000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x281e5000)
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x28300000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x28340000)
libthr.so.3 => /lib/libthr.so.3 (0x28481000)
ということなので、nss_ldap.so.1からlibthr.so.3が引きずりだされているみたいです。
nss_ldap.soが使われるのは、/etc/nsswitch.confにldapを使うようにかかれていたためです。ためしに、/etc/nsswitch.confを別のファイル名に変更してみると、scanは動きました。
ということは、LDAPを使っていない環境では、Wnn7のjserverも動くんでしょうね。
ちなみに、nss_ldap.soは、libcが要求しているみたいです。こんないい加減な方法で、さぐってみました（笑）。
# strings "/usr/local/lib/compat/libc.so.5" | grep nss
__nss_compat_getgrnam_r
__nss_compat_getgrgid_r
__nss_compat_getgrent_r
__nss_compat_setgrent
__nss_compat_endgrent
__nss_compat_getpwnam_r
__nss_compat_getpwuid_r
__nss_compat_getpwent_r
__nss_compat_setpwent
__nss_compat_endpwent
/etc/nsswitch.conf
nss_%s.so.%d ← これがそうらしい
nss_module_register
nss_load_module
nss_method_lookup
というわけで、libthrが使われる原因は、nss_ldap.soにあることがわかりました。
■ （オマケ） nsswitch.confって切り替えられないの？
じゃあ、scanを実行するときは、別のnsswitch.confを使わせればいいじゃない？と思って、ソースをしらべてみると・・・セキュリティホールになるので、それはできない、とのこと。
lib/libc/net/nsdispatch.c にて
/*
* The first time nsdispatch is called (during a process's lifetime,
* or after nsswitch.conf has been updated), nss_configure will
* prepare global data needed by NSS.
*/
static int
nss_configure(void)
{
static pthread_mutex_t conf_lock = PTHREAD_MUTEX_INITIALIZER;
static time_t confmod;
struct stat statbuf;
int result, isthreaded;
const char *path;
result = 0;
isthreaded = __isthreaded;
#if defined(_NSS_DEBUG) && defined(_NSS_SHOOT_FOOT)
/* NOTE WELL: THIS IS A SECURITY HOLE. This must only be built
* for debugging purposes and MUST NEVER be used in production.
*/
path = getenv("NSSWITCH_CONF");
if (path == NULL)
#endif
path = _PATH_NS_CONF;
■ （オマケ） jserverはどうよ？
jserverで同じことをやってみると、libthrは呼ばれていない？
もしかして、子processをforkして、ktraceでは見えていないのでしょうか。
35183 ktrace NAMI "/usr/local/bin/jserver"
35183 ktrace NAMI "/libexec/ld-elf.so.1"
35183 jserver NAMI "/etc/libmap.conf"
35183 jserver NAMI "/usr/X11R6/lib/libxpg4.so.3"
35183 jserver NAMI "/var/run/ld-elf.so.hints"
35183 jserver NAMI "/lib/libxpg4.so.3"
35183 jserver NAMI "/usr/lib/libxpg4.so.3"
35183 jserver NAMI "/usr/lib/compat/libxpg4.so.3"
35183 jserver NAMI "/usr/local/lib/libxpg4.so.3"
35183 jserver NAMI "/usr/local/lib/compat/pkg/libxpg4.so.3"
35183 jserver NAMI "/usr/local/lib/compat/libxpg4.so.3"
35183 jserver NAMI "/usr/local/lib/compat/libxpg4.so.3"
35183 jserver NAMI "/usr/X11R6/lib/libcrypt.so.2"
35183 jserver NAMI "/lib/libcrypt.so.2"
35183 jserver NAMI "/usr/lib/libcrypt.so.2"
35183 jserver NAMI "/usr/lib/compat/libcrypt.so.2"
35183 jserver NAMI "/usr/local/lib/libcrypt.so.2"
35183 jserver NAMI "/usr/local/lib/compat/pkg/libcrypt.so.2"
35183 jserver NAMI "/usr/local/lib/compat/libcrypt.so.2"
35183 jserver NAMI "/usr/local/lib/compat/libcrypt.so.2"
35183 jserver NAMI "/usr/X11R6/lib/libc.so.5"
35183 jserver NAMI "/lib/libc.so.5"
35183 jserver NAMI "/usr/lib/libc.so.5"
35183 jserver NAMI "/usr/lib/compat/libc.so.5"
35183 jserver NAMI "/usr/local/lib/libc.so.5"
35183 jserver NAMI "/usr/local/lib/compat/pkg/libc.so.5"
35183 jserver NAMI "/usr/local/lib/compat/libc.so.5"
35183 jserver NAMI "/usr/local/lib/compat/libc.so.5"
35183 jserver NAMI "/etc/malloc.conf"
35183 jserver NAMI "/usr/local/lib/wnn7/msg/libwnn.msg"
35183 jserver NAMI "/"
■ /etc/libmap.confで対処してみる
これまでlibmap.confをいじったことがなくて、よくわかんなかったのですが、libmap.confは、ダイナミックローダが共有ライブラリをリンクするときに、ライブラリを無理やり付け替える、つまり、本来とは別のライブラリをリンクさせられるようにする機能らしいです。
nss_ldap.so.1を別のライブラリに付け替えてしまえばいいのですが、どうすればいいんだろう？ と思って、えいや、とlibc.so.5にしてしまいました。ようするに、nss_ldapが動かなくなっちゃうわけなんですが、/etc/libmap.confにこんな風に書いてみる。
[scan]
nss_ldap.so.1 libc.so.5
[show]
nss_ldap.so.1 libc.so.5
[mhn]
nss_ldap.so.1 libc.so.5
[mhl]
nss_ldap.so.1 libc.so.5
[/usr/local/bin/jserver]
nss_ldap.so.1 libc.so.5
これで、実は、なんとなく動いてしまいました。
ちなみに
[/usr/local/bin/scan]
と書くと、コマンド名が「/usr/local/bin/scan」で実行したときだけlibmap.confでライブラリが付け替えられて、「scan」と実行したときはlibmap.confのマッピングルールは適用されなくなるのでした。試行錯誤しているとき、これに気がつかず、遠回りしてしまいました。
これでいいのか？というと、当然のことながら、ダメです。LDAPでpasswdやgroupがひけなくなってしまうのです。
■ ちゃんとnss_ldap.soが動くようにする
FreeBSD6なホストから、nss_ldap.so.1をもらってくることにしました。
FreeBSD6なホストで確認。
% ldd /usr/local/lib/nss_ldap.so.1
/usr/local/lib/nss_ldap.so.1:
libldap-2.3.so.2 => /usr/local/lib/libldap-2.3.so.2 (0x88189000)
liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x881ba000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x881c5000)
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881da000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x88213000)
% ldd /usr/local/lib/libldap-2.3.so.2
/usr/local/lib/libldap-2.3.so.2:
liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x8819f000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x881aa000)
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881bf000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x881f8000)
となっているので、FreeBSD6の以下のファイルを、
/usr/local/lib/nss_ldap.so.1
/usr/local/lib/libldap-2.3.so.2
/usr/local/lib/liblber-2.3.so.2
/usr/local/lib/libsasl2.so.2
/usr/local/lib/libssl.so.5
/usr/local/lib/libcrypto.so.5
FreeBSD7なホストへコピーします。同名のファイルがありますので、とりあえず
/usr/local/lib/compat/freebsd6/
というディレクトリを作って、そこへコピーしました。
結局、私の環境では、/etc/libmap.conf は次のようになりました。
[/usr/local/lib/compat/freebsd6/nss_ldap.so.1]
libldap-2.3.so.2 freebsd6/libldap-2.3.so.2
liblber-2.3.so.2 freebsd6/liblber-2.3.so.2
libsasl2.so.2 freebsd6/libsasl2.so.2
libssl.so.5 freebsd6/libssl.so.5
libcrypto.so.5 freebsd6/libcrypto.so.5
[/usr/local/lib/compat/freebsd6/libldap-2.3.so.2]
liblber-2.3.so.2 freebsd6/liblber-2.3.so.2
libsasl2.so.2 freebsd6/libsasl2.so.2
libssl.so.5 freebsd6/libssl.so.5
libcrypto.so.5 freebsd6/libcrypto.so.5
[scan]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[show]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[mhl]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[/usr/local/bin/jserver]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[wnnstat]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[/sge/utilbin/fbsd-i386/]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[/sge/bin/fbsd-i386/]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
[/sge/lib/fbsd-i386/]
nss_ldap.so.1 freebsd6/nss_ldap.so.1
これで、とりあえずちゃんと動いているみたいです。
■ （オマケ）/usr/local/lib/compat/pkg/nss_ldap.so.1
こっちは、portupgradeしたときに上書きされるやつなので、今回の目的には使えません。そもそも、FreeBSD7用のバイナリですから。
# ldd /usr/local/lib/compat/pkg/nss_ldap.so.1
/usr/local/lib/compat/pkg/nss_ldap.so.1:
libldap-2.3.so.2 => /usr/local/lib/libldap-2.3.so.2 (0x2819f000)
liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x281d6000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x281e3000)
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x28300000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x28340000)
libc.so.7 => /lib/libc.so.7 (0x28088000)
libthr.so.3 => /lib/libthr.so.3 (0x28481000)
■ （オマケ） libmap.confの書き方を間違えた
最初、nss_ldap.so.1だけを/usr/local/lib/compatへコピーして、libmap.confに、これだけを書いてみたら・・・
[scan]
nss_ldap.so.1 /usr/local/lib/compat/nss_ldap.so.1
うまくいく。これでいいのかと思ったら、間違ってました。
こういう風に、libthrが使われるはずなんだけど、なぜうまくいくのだろうか？
# ldd /usr/local/lib/compat/nss_ldap.so.1
/usr/local/lib/compat/nss_ldap.so.1:
libldap-2.3.so.2 => /usr/local/lib/libldap-2.3.so.2 (0x2819f000)
liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x281d6000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x281e3000)
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x28300000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x28340000)
libc.so.7 => /lib/libc.so.7 (0x28088000)
libthr.so.3 => /lib/libthr.so.3 (0x28481000)
ktraceしたらわかりました。
52188 scan NAMI "/usr/local/lib/mplayer/vidix/nss_dns.so.1"
52188 scan NAMI "/usr/local/lib/mysql/nss_dns.so.1"
52188 scan NAMI "/usr/local/lib/nss/nss_dns.so.1"
52188 scan NAMI "/usr/local/lib/pth/nss_dns.so.1"
52188 scan NAMI "/usr/local/lib/wine/nss_dns.so.1"
52188 scan NAMI "/lib/nss_dns.so.1"
52188 scan NAMI "/usr/lib/nss_dns.so.1"
52188 scan NAMI "/usr/local/lib//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/lib//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/lib//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/lib/compat//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/compat/pkg//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/compat//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/gcc-4.2.3//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/graphviz//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/kde3//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/mplayer/vidix//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/mysql//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/nss//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/pth//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/wine//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/lib//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/lib//usr/local/lib/compat/nss_ldap.so.1"
52188 scan NAMI "/usr/local/lib/nss_compat.so.1"
52188 scan NAMI "/lib/nss_compat.so.1"
52188 scan NAMI "/usr/lib/nss_compat.so.1"
52188 scan NAMI "/usr/lib/compat/nss_compat.so.1"
52188 scan NAMI "/usr/local/lib/nss_compat.so.1"
ようするに、nss_ldap.so.1が見つからなくなって、nss_ldap.soが無効になってるだけのことでした。
う～ん、libmap.confって、奥が深い！
nss_ldap.so.1以外にも、あれこれファイルが必要なのは、以下のように、みんな、あれこれたくさん依存関係をひきづっているためです。
% ldd /usr/local/lib/libsasl2.so.2
/usr/local/lib/libsasl2.so.2:
libc.so.7 => /lib/libc.so.7 (0x28088000)
% ldd /usr/local/lib/libssl.so.5
/usr/local/lib/libssl.so.5:
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x28300000)
libthr.so.3 => /lib/libthr.so.3 (0x281c4000)
libc.so.7 => /lib/libc.so.7 (0x28088000)
% ldd /usr/local/lib/libcrypto.so.5
/usr/local/lib/libcrypto.so.5:
libthr.so.3 => /lib/libthr.so.3 (0x28184000)
libc.so.7 => /lib/libc.so.7 (0x28088000)
libmap.confでの対策が不完全なときは、こんな風にlibthrが入ってしまいます。
# ldd /usr/local/lib/compat/freebsd6/libldap-2.3.so.2
/usr/local/lib/compat/freebsd6/libldap-2.3.so.2:
liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x281b5000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x281c2000)
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x28300000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x28340000)
libc.so.7 => /lib/libc.so.7 (0x28088000)
libthr.so.3 => /lib/libthr.so.3 (0x281d9000)
一通り、libmap.confでマッピングルールを入れてやれば、こうなりました。
% ldd /usr/local/lib/compat/freebsd6/nss_ldap.so.1
/usr/local/lib/compat/freebsd6/nss_ldap.so.1:
libldap-2.3.so.2 => /usr/local/lib/compat/freebsd6/libldap-2.3.so.2 (0x2819f000)
liblber-2.3.so.2 => /usr/local/lib/compat/freebsd6/liblber-2.3.so.2 (0x281d0000)
libsasl2.so.2 => /usr/local/lib/compat/freebsd6/libsasl2.so.2 (0x281db000)
libssl.so.5 => /usr/local/lib/compat/freebsd6/libssl.so.5 (0x28300000)
libcrypto.so.5 => /usr/local/lib/compat/freebsd6/libcrypto.so.5 (0x28339000)
% ldd /usr/local/lib/compat/freebsd6/libldap-2.3.so.2
/usr/local/lib/compat/freebsd6/libldap-2.3.so.2:
liblber-2.3.so.2 => /usr/local/lib/compat/freebsd6/liblber-2.3.so.2 (0x281b5000)
libsasl2.so.2 => /usr/local/lib/compat/freebsd6/libsasl2.so.2 (0x281c0000)
libssl.so.5 => /usr/local/lib/compat/freebsd6/libssl.so.5 (0x28300000)
libcrypto.so.5 => /usr/local/lib/compat/freebsd6/libcrypto.so.5 (0x28339000)
(2007/12/5 追記)
ここに書いた方法で動かしたGridEngine(SGE)ですが、ちゃんと動いてませんでした。あれ？
ジョブが割り当てられたとき、ログイン名をLDAPで引けてない、って感じのエラーメッセージが出てました。ソースを少しながめた限りでは、getpwnam_r()でエラーが出てる雰囲気がしたので、簡単なプログラムを書いて試したんですけど、うまく動きました。なんだろう？
- getpwnam_r()を使った簡単なテストプログラムを書く。
- FreeBSD6でコンパイル。一応実行できることを確認。
- FreeBSD7で実行。動かないことを確認。
- FreeBSD7でlibmap.confにルールを追加。動くことを確認した。
libmap.confを使わずに、FreeBSD6とFreeBSD7とでアーキテクチャ名を変えられれば、それが一番いいんですけど。FreeBSDのportsでビルドするときSGE_ARCHで指定できそうだったんですが、ダメでした。
(2007/12/11 追記)
ふと気がつけば、FreeBSD 6-STABLEなマシンでも、wnnenvutilなどで、一部のライブラリのnot foundになってました。
# ldd /usr/local/bin/wnnenvutil
/usr/local/bin/wnnenvutil:
libxpg4.so.3 => /usr/lib/libxpg4.so.3 (0x280b2000)
libgtk12.so.2 => not found (0x0)
libgdk12.so.2 => not found (0x0)
libgmodule12.so.3 => not found (0x0)
libglib12.so.3 => not found (0x0)
libintl.so.5 => not found (0x0)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x280e7000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x280ef000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x280fc000)
libc.so.5 => /usr/local/lib/compat/libc.so.5 (0x281e1000)
libXau.so.6 => /usr/local/lib/libXau.so.6
libm.so.2 => /usr/lib/compat/libm.so.2 (0x280b4000)
libcrypt.so.2 => /usr/local/lib/compat/libcrypt.so.2 (0x280cf000)
libgtk12.so.2 => not found (0x0)
libgdk12.so.2 => not found (0x0)
libgmodule12.so.3 => not found (0x0)
libglib12.so.3 => not found (0x0)
libintl.so.5 => not found (0x0)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x280e7000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x280ef000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x280fc000)
libc.so.5 => /usr/local/lib/compat/libc.so.5 (0x281e1000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x282bb000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x282be000)
librpcsvc.so.3 => /usr/lib/librpcsvc.so.3 (0x282c3000)
どうも、ライブラリのファイル名がある時期から変更されているみたいなので（例： libgtk12.so.2が、libgtk-12.so.2へ）、/etc/libmap.confでマッピングを指定してみました。
libgdk12.so.2 libgdk-12.so.2
libgtk12.so.2 libgtk-12.so.2
libgmodule12.so.3 libgmodule-12.so.3
libglib12.so.3 libglib-12.so.3
あと、libintl.so.5が行方不明になってしまっていたので、たまたまそのファイルがあったマシンから/usr/local/lib/compat/pkg/にコピーしました。
# ldd /usr/local/bin/wnnenvutil
/usr/local/bin/wnnenvutil:
libxpg4.so.3 => /usr/lib/libxpg4.so.3 (0x280b2000)
libm.so.2 => /usr/lib/compat/libm.so.2 (0x280b4000)
libcrypt.so.2 => /usr/local/lib/compat/libcrypt.so.2 (0x280cf000)
libgtk12.so.2 => /usr/X11R6/lib/libgtk-12.so.2 (0x280e7000)
libgdk12.so.2 => /usr/X11R6/lib/libgdk-12.so.2 (0x28205000)
libgmodule12.so.3 => /usr/X11R6/lib/libgmodule-12.so.3 (0x28238000)
libglib12.so.3 => /usr/X11R6/lib/libglib-12.so.3 (0x2823b000)
libintl.so.5 => /usr/local/lib/compat/pkg/libintl.so.5 (0x28263000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x2826c000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x28274000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x28281000)
libc.so.5 => /usr/local/lib/compat/libc.so.5 (0x28366000)
libm.so.4 => /lib/libm.so.4 (0x28440000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28456000)
libc.so.6 => /lib/libc.so.6 (0x2845f000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2854f000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x28645000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x28648000)
librpcsvc.so.3 => /usr/lib/librpcsvc.so.3 (0x2864d000)
0 件のコメント:
コメントを投稿