中身はこんな感じ。
$ ldd /usr/lib/im/htt_server
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4001e000)
libdl.so.2 => /lib/libdl.so.2 (0x40134000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40138000)
libc.so.6 => /lib/libc.so.6 (0x4014b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
…まさかpthreadってことはあるまい。glibcまわりはstableで押さえているので、まず間違いネェだろう。ということは、libX11っぽい。
実はうちのXはXF86-4.0.1の野良ビルド。地雷原でメモリリークしまくり、という話はKondara情報で入手済みだったので、こりゃビルドし直しかな。
…これが、長い旅のはじまりになってしまった。
とりあえず野良でいいから最新のスナップショット拾ってこようと、CVSupで拾ってくる。よせばいいのに、手元にミラーがあればいいなとリポジトリ複製するよう設定。…これだけで64Kの細い回線では5〜6時間かかってしまった（寝てしまったので正確にどれくらいかかったかは不明）。
続いて、最新とおぼしきタグでexportしていざビルド、インストール。ところが、_XSERVうんちゃらというエラーが出て、Xそのものが起動しなくなってしまった。
こういう時、普段はちゃんとバックアップをとる。ところが今回は、以前野良ビルドしたソースが転げたまま残っていたので「大丈夫でしょう」とバックアップをとらなかった。
ところがこれが大間違い。以前ビルドしたときはegcsを使っていたらしいのだが、現在はegcs環境を全部消してしまっていて、pgccがその座に納まっている。ところがXのmakedependがegcsのヘッダを依存関係として参照していたようで、make installできずにコケてしまった。
さて困った。何がいけない？野良ビルドの4.0.1-snapが動かない原因を探すのが先か、とりあえず動く環境を準備するのが先か。
悩んでいる余裕はなかったので、Kondara-Jiraiから4.0.1のRPMを拾ってくる。
けれどもJirai環境はすでにglibc-2.95系（実際には2.96）に移行してるんだよ。バイナリ拾ってきたら、GLIBC_2.2に依存すると言われてNG。
さすがにglibcを上げるほどの冒険はできないから、フルソースとnosrc.rpmを拾ってきてrebuild。
…いかん、野良ビルドと同じ現象で起動しない。
ハテと思い立って、コンパイルオプションを疑う。
optflags: i386 -O9 -Os -mcpu=k6 -pipe -funroll-all-loops
としていたのだけど、XFree86サーバが吐くエラーメッセージ自体が壊れているので、K6最適化がらみが悪さをしているんじゃないかと思ったのだ。（ちなみにターゲットの石は初代Athlon 550MHz）
こんなの滅多にないことなんだけど、たまーにこれで引っかかるプロダクトがあったりしたので、可能性はゼロじゃない。
Linux on an Athlonによると、K7は-mcpu=pentiumproを受け付ける（つまり、PentiumProのインストラクションを受け付ける）らしいので、
optflags: i386 -O9 -Os -mcpu=pentiumpro -pipe -funroll-all-loops
として「頼むぜぇ」と再コンパイル。
結果、やっと無事に動くRPMが出来上がった。
XFree86のコンパイル、K7-550でも一回あたり2〜3時間はかかる。ここまでたどりつくのにどれだけかかった？…考えたくもない。
さて、肝心のhtt_serverの消費メモリはどうなったかというと…？
さすがに、以前のような120MBなんてキ○ガイみたいなことはなくなった。けど、やっぱり少しづつメモリリークしてるような…
まぁ、今回はいろいろ勉強になったし、よしとするか。
副産物として、Xそのもののメモリ消費量も減ったし。（やっぱリークしてたんかい(--;）
| 
