トロピカーナ スパークリング
ヌーヴォー
なんとなく名前からあれを連想しますが、お酒ではありません。
「2007年収穫グレープ限定使用」だとか。
濃縮還元ですが、果汁100%。
予想してたほど、甘ったるくはありませんでした。
ところで、今年の夏まで、2006年のボジョレー・ヌーヴォーを売ってたコンビニがあったんですが・・・
トロピカーナ スパークリング
ヌーヴォー
なんとなく名前からあれを連想しますが、お酒ではありません。
「2007年収穫グレープ限定使用」だとか。
濃縮還元ですが、果汁100%。
予想してたほど、甘ったるくはありませんでした。
ところで、今年の夏まで、2006年のボジョレー・ヌーヴォーを売ってたコンビニがあったんですが・・・
えーと、まだ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で再ビルドでいいのですが、できないもの、たとえば、
などでは、コンパイルしなおすことはできません。
そういうときは、どうすりゃいいんだい?
/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()でエラーが出てる雰囲気がしたので、簡単なプログラムを書いて試したんですけど、うまく動きました。なんだろう?
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)
「古代王者 恐竜キング Dキッズ・アドベンチャー」というアニメ。
私は見てないんですけど、次回の放映作品のサブタイトルが、なんか気になりました。
シベリア恐竜特急
子供には、わかるまい(笑)。
予告では、シベ超とは無関係ぽかったですけど、一応チェックすべきかな?
ちょうど今ごろ、一番注意しなければならないのが、コレ。
犬の毛にくっついちゃうと、とるのが大変。
これまで、ずっと、アメリカセンダングサだと思い込んでいたのですが、実は違うみたい。
コシロノセンダングサ、もしくは、コセンダングサみたいです。
どこで間違った知識が注入されたんだろう?
このセンダングサですが、昔に比べて、ものすごく増えた気がします。
☆
しっかりと見張っていないと、すぐに草むらに突入していってしまう・・・
昔、NHKとかが、ハイビジョンを普及させるために、走査線の本数1125にちなんで、11月25日をハイビジョンの日と決めて、宣伝活動などをしてました。
もっともそのときのハイビジョンってのは、アナログ方式のもので、アナログハイビジョンは、2007年9月30日に終了してしまいました。
それと入れ違いに、デジタル方式のハイビジョンが、衛星放送、地上波でそこそこ広まってきてはいます。
アナログハイビジョンってのは、時代が早すぎた、って感じなんでしょうか。
☆
NHKはチャンネル数が多すぎだ、という意見があって、とりあえず衛星を1つ減らしましょうか?てなことから、NHK BS hiが切り捨てられる話がありましたが、どうなってるんでしょうか。
最近のドラえもんのアニメやキャラクターグッズなどでは、顔の真ん中に大きな目がついていることが多いようですが、原作マンガでは、実際にはそんなに大きくなくて、しかも顔の上の方についてるんですよね。
どっかの評論家みたいな人が昔言ってたんですけど、顔の上のほうにあるのは、お母さんが子供をやさしく見つめる目線を表現してるとかなんとか。日本のマンガ・アニメでは、目が顔の中央あたりについてるのが定番で、上のほうにあるのはかなりめずらしいとか。
☆
突然そんなことを思い出したのは、最近、「しおんの王」を見て、それはやりすぎじゃないか?と違和感を感じたので・・・
欧米人には、日本独特のアニメ・キャラの大きな目が、まるで宇宙人かのように見えると聞いたことがありますが、これは私にも宇宙人に見えました。
ただこれは回想シーンの絵で、レンズで光学的に絵をゆがませたようなエフェクトがかかっているため、余計にそう見えるだけなのかもしれません。
☆
ドラえもんですが、デフォルメされるし、デザインを厳密には統一しない大らかさがあったのか、コマによって、目の大きさ、位置は、けっこうバラバラですね。必ずしも、小さくて上の方とは限らないようです。手描きの味あいがありますね。
なんだこりゃ?!
コミックス収録作品で、絵がなんか違うなと感じるもの中には、トレースのせいだったりするとか。
久々に、思い出の品物シリーズ(そんなシリーズあったのかい?)。
カシオのQV-10を貸してもらって、デジカメすごくいい!と感動し、そのあと、自分で初めて買った、デジタルカメラです。
DS-7 (富士フイルム)
CLIP-ITは、愛称なんだそうです。
「フジフイルム デジタルカメラ DS-7 ”クリップ・イット”」http://www.fujifilm.co.jp/news_r/nrj100.html
平成8年7月12日発売だそうです。私が買ったときは5万円くらいでした。
11年の間に、デジカメも相当に進歩したものですね。
☆
けっこう大きいです。シャツの胸ポケットには、ぜんぜん入りません。
裏側。液晶ディスプレイがあるくらいで、今のデジカメと比べたら、すっきりしてますね。
QV-10の液晶表示がもっさりしてたのに対して、DS-7のはイイ感じでした。
ダイヤルがついてるのは今のデジカメに通じるところがあります。
ただし、今のデジカメのダイヤルは、主に撮影モードの切り替えだったりしますけど、DS-7には、撮影モードなんていう概念が無いですね。基本的に、撮影するか、見るか、だけ。
電池は、単3が4本。そういえば、QV-10って、電池すぐ切れましたね。DS-7も、まあ、そんな持ちませんでした。私はQV-10でたっぷり学習したので、最初からニッカド電池を使ってました。あのころ単3のニッカドの容量は1000mAhが最大でした。SANYOのカドニカ・・・あのときSANYOはバッテリでは一流メーカーだ、と知ったんだっけ。
記録メディアはスマートメディア(SmartMedia)。上のURLのページを見たら、SSFDCと書いてありました。え?
SSFDCって聞いた覚えがあるような感じがするけど、何だっけ?と調べてみると、Solid State Floppy Disc Cardの略だそうで、すぐにスマートメディアに名称が変わってました。
切手サイズのメモリーカード「SSFDC」を
「スマートメディア」に名称変更
'96/10/15 発表
http://pc.watch.impress.co.jp/docs/article/961016/ssfdc.htm
今ではあまり見かけなくなったスマートメディア。DS-7は、これを採用したはじめての製品でした。QV-10は、メモリは本体内蔵のものしかなかったので、これって、画期的な進歩だと思っていました。
この写真は4MBですが、最初は、2MBの容量でした。仲間内で、
すげー、こんな小さいのにフロッピーディスク1枚分以上のデータが記録できるんだ。いいねぇ。
とか話していたのは、懐かしい思い出です。
ところで、ちょっと待ってください。上のスマートメディア、普通よく知られているのとは、規格が違うのです。
よく使われていたほうのはこちら。
切り欠き(斜めにかけている部分)の位置が、逆なんです。
DS-7で使われていたのは、電圧が5Vタイプのものでして、この規格の品は、あっという間に消え去り(笑)、3.3Vタイプのものになってしまいました。
スマートメディアは、「切手サイズ」と言われてましたが、かなり大型の記念切手程度の大きさでしたね。
まあ、宣伝文句というのはそういうものですよね。昔よく言われていたことですが、
という感じで。
☆
スマートメディアを読み書きするためのPCカードアダプタ。
SSFDCって書いてありますね。
この隙間にスマートメディアをさします。