Satoshi MACHINO
machi****@vinel*****
2004年 1月 9日 (金) 17:53:00 JST
まちの です。 On Fri, 09 Jan 2004 17:28:36 +0900 Yukinobu Hamuro <hamur****@adm*****> wrote: > こちらで、rpm --recompile musashi-1.0.3-0.pre2.src.rpm > を実行した際のログを見ると、ご指摘のコンパイルについては、以下のようにlibiconvを利用していないようになっています。 > なぜでしょうか？？ 補足でも書きましたが 羽室先生のrebuildされたPCにlibiconvはインストールされていますか? 1.0.3-pre1をインストールされていた環境では (この対象が少ないので無視しても良いかもしれません) libiconvがPCにインストールされているはずです。 その状態でrebuildするとconfigureではiconvを探すのでOKなのですが 実際のコマンドをbuild時になぜか -Iされてます。 > ・glibcのパッケージから提供されるライブラリ(libc.so)には、既にiconv関連の関数(iconv_open()やiconv()など)が既に実装されている。 おそらく。 > ・それらの関数が呼び出されたときは、/usr/lib/gconvの下にある各種エンコーディング変換モジュールが動的に呼び出される。 はい。 > ・すなわちlibiconvライブラリは利用されておらず、必要ない。 少なくともlinuxで言えば glibc-2.2.x以降のバージョンであれば libiconvは必ずしも必要ないはずです。 # glibcに含まれるiconvで機能不足な何かがあればlibiconvの方が # 必要になる事は十分考えられます。 > ・一方で、Cygwin環境のglibcでは、gconvが付属していない。 すみません、これはよくわかりませんが おそらくそうなのでしょう。 Linux以外には普通含まれないと思いますし... # FreeBSDとかにもないはずです、そもそもglibcと言わないかな。 > ・そのため、libiconv.soが必要となる。 .soが必要になるかはまた別ではないでしょうか? glibcのiconvはlib化はされていません。 あくまでiconv()のみです。 > ただ、上でご指摘されたように、SRPMからrebuidした時にlibiconv.soをリンクしているというのは疑問が残りますが。。。 > なぜでしょうか？ ですから、これはrebuild時にlibiconvがあれば configureでは見ていないけど実際はリンクされるという事だと思います。 # cygnusと同じ状況になる > 結論を言うと、MUSASHIのLinux上では、libiconv.soは必要ないと考えます。 わかりました。 libiconvのない環境では問題なくrebuildできましたので 大勢に問題ないと思います。 お騒がせしました。 -- Satoshi MACHINO <machi****@yendo*****> <machi****@vinel*****> GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32
