[[diary/Kojima]]
・libffi
x86とx86_64で、だいたいパッケージのバージョンを揃え終って、
次に依存関係を整理しようとライブラリ回りを眺めているのだけど、
ちと困ったことが。
具体的には、libffi.soのバージョンが、4,5,6 の三種類あって、
さてどれに揃えたものか、、というところ。
もともとffiは、Foreign Function Interfaceの略だそうで、
CのライブラリをC以外の言語から呼び出す際に被せるレイヤー的な機能を提供するライブラリだそうで、
当初はGCCのうちのgcjと一緒に配布されていた(libffi.so.4)
ところが、この機能を使うソフトウェアが多数になってきたので、
最近ではlibffiはGCCとは独立したライブラリとして開発されており、
ここしばらくはlibffi.so.5が広く利用されていた。
一方、今年の4月にリリースされたlibffi-3.0.11では、
それ以前のlibffi-3.0.10とは異なり、共有ライブラリのsonameを上げてlibffi.so.6にしたので、
libffi.so.5を参照している大量のバイナリが動かなくなってしまった。
とりあえず libffi.so.5 -> libffi.so.6 のリンクを張れば動くようなので、
現在はその状態で動かしてはいるものの、この先、
libffiが今回のようにリリース番号が変わるくらいでsonameを変更するようなバージョンアップを繰替えすようなら、
バイナリファイルを追従させるのが大変なので、
libffi-3.0.xのlibffi.so.[56] ではなくGCCに付属のlibffi.so.4を使うようにした方がいいのではないかと思う今日このごろ。
でも、libffi.so.4はlaファイルだけでpkgconfigは提供していないから、
libffi.soをlibffi.so.4に向けていても、
pkgconfigを引くソフトはlibffi.so.6をリンクしに行っちゃうんだよなぁ。。
ちなみに現状では、
$ ./query_depends.py -s libffi.so.6 | wc -l
367
$ ./query_depends.py -s libffi.so.5 | wc -l
1015
$ ./query_depends.py -s libffi.so.4 | wc -l
69
となっていて、libffi.so.5を参照していて（誤魔化してlibffi.so.6を見せている）
バイナリが一番多いのだけど、これらをlibffi.so.6を見るように直していると、
libffi.so.7 なんてのが出てきて、また同じ目に遭いそうなんだよなぁ。。
- 歴史的に見ると、libffiのプロジェクトが先にあって、GCJはそれを使うためにある時点のコードを自前に取り込んだ、というのが正しいらしい。まぁ、逆に言うと、GCJが使い出したころからlibffiはコロコロと変っていて扱い切れなかったことの証左という気はするな。 -- [[kojima]] &new{2012-09-19 (水) 11:04:48};
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
