2007/10/24
Document Actions
AirOne v4.8βのGNU/Linux版リリース
AirOne v4.8βのGNU/Linux版をリリースしました。
β版と言っていますが、コードベースはWindows版と同じです。
数年前はg++の過渡期で、バイナリ互換性に問題がありました(g++2.9、g++3.0、g++3.1の頃の話)。 g++のバイナリ互換性の問題もなくなり、配布バイナリはひとつで済むかと思っていたら、思わぬ罠がありました。GNU libcのバージョン問題です。
Ubuntu6でビルドしたバイナリを古いFedoraで動かそうとするとlibcにGLIBC_2.4シンボルが無いと怒られて起動しません。 結局、ふたつのバイナリを配布することになりました。
$ strings /lib/libc.so.6 | grep GLIBC
で、GNU libcのバージョンを調べて、必要なバイナリを取得してください。
ぼくの記憶では、shared libraryがバイナリ互換性を失うメジャーアップグレードの場合は、ファイル名のバージョン番号(上の例では6の部分)を変える仕組みだった気がします。記憶ではSVR4由来の仕組みだったと思いますが、GNUにとってはどうでも良い慣習なのでしょうか。
- Category(s)
- カテゴリなし
- The URL to Trackback this entry is:
- http://dev.ariel-networks.com/Members/inoue/airone48-gnulinux/tbping
ただ、libc のように多くのライブラリからも参照される側のライブラリだと、安易にSONAMEを変えるわけにはいきません。というのは、libc.so.6 を参照するようにコンパイルされた libfoo.so.1 を必要とするアプリケーションAと、libc.so.7 を参照するようにコンパイルされた libfoo.so.1 を必要とするアプリケーションBがあったときに、AとBの混在ができなくなるからです。このためlibcのSONAMEは、よほどのことがない限り変更しないように運用するのが普通です。(こういうことを全然考慮しないフリーなUNIX系OSもありますが…)
くだんの件については、古いFedora用のバイナリだけを用意しておけば、Ubuntu6でも動きませんか？
> くだんの件については、古いFedora用のバイナリだけを用意しておけば、Ubuntu6でも動きませんか？
動きますし、動作確認もしていますが、なんとなく「集合の中で一番低いバージョンに合わせる」という態度が、まるで、共通する部分集合の機能しか利用しないマルチプラットフォーム対応GUIライブラリのようで嫌なので、GLIBC_2.4版も置きました。簡単に言えば、ただの自己満足です。
通常、ABI に関して保証されるのは上位互換性のみですから。
これは別に glibc に限らず、いにしえの SunOS4 でも、あるいは Windows でも同じであり、古い OS と新しい OS の両方で動かすバイナリは、古い OS 向けでビルドしておく必要があると思いますが…
上位互換性と違って、下位互換性の維持は現実的には不可能なので、いつか失うのは必然です。この是非は別にどうでもよくて、下位互換性を失った時はlibc.so.7になるべきかと思ったのが発端です。上位互換まで失った時がlibc.so.7の登場なのかもしれません。
はい。そうです。