共有ライブラリで導入された発行物で,最も難しいものは,実行時の依存性の
作成と解決です.プログラムとライブラリの依存性は,sed
のような単
一の名前の用語で,よく記述されます.そのため"libtoolはsedに依存する"
と告げ,それで十分目的を果たせます.
しかし,規則的にインターフェースが変更されるとき,我々はより具体的に告 げる必要があります."Gnus 5.1はEmacs 19.28以上を要求する."ここでは, 名前からなるインターフェースの記述と"バージョンナンバー"です.
種類の説明はいくつかの目的において十分でないことすらあります.Emacs 20 で変更された場合,Gnus 5.1を破壊するのに十分ではないでしょうか?
同じ問題は,共有ライブラリでも存在します.我々は,プログラムが必要とし ているインターフェースを提供するライブラリのみとリンクされることを,ダ イナミックリンカが保証できるように,プログラムが依存する共有ライブラリ を記述するために,公式なバージョン管理システムが必要です.
ライブラリのインターフェースは,以下の何か(またはそれ以上)でしょう.
スタティック関数は,ライブラリのユーザが直接利用不可能なので,インター フェースに数えられないことに注意してください.
libtoolは独自の公式のバージョン管理システムがあります.それは,あまり 柔軟ではありませんが,強力なバージョン管理システムで,確かに最も単純で す.
ライブラリとは,整数で任意に表示できるインターフェースのいくつかの組を エクスポートするものだと考えて下さい.プログラムがライブラリとリンクさ れるとき,これらのインターフェースのサブセットを利用するかもしれません.
プログラムが使用するインターフェースのlibtoolの記述は単純です.それは, 結果のバイナリにある最大と最小のインターフェースの番号を符号化します (first-interface, last-interface).
ダイナミックリンカは,ライブラリがfirst-interfaceと last-interfaceの間のすべてのインターフェースの番号をサポー トする場合,プログラムがライブラリとリンク可能なことを保証します.
libtoolの移植性の要求が,実際に必要と言うよりは厳密なので,問題を生じ る可能性があることに注意してください.
さて,`libhello'がインターフェースの5,16,17,18,と19をサポート し,libtoolは`libhello'を`test'にリンクするとき使用されると 仮定します.
libtoolは`test'に数字5と19を符号化し,ダイナミックリンカは,5と19 の間のすべてのインターフェースをサポートしているライブラリのみ と,`test'をリンクします.そのため,ダイナミックリンカは `libhello'と`test'をリンクすることを拒否するのです!
この問題を排除するために,libtoolはライブラリは,連続したインターフェー ス番号を宣言することのみ可能としています.そのため,`libhello'は, 16 から19までのインターフェースをサポートすることを宣言するのが精一杯 です.そして,ダイナミックリンカは,`libhello'を`test'とリン クします.
そのため,libtoolライブラリバージョンは,三つの整数で宣言されます.
current - age
から
current
までの番号の範囲で,すべてのインターフェース番号を
実装しています.
二つのライブラリが,個別のcurrentとageを持つ場合,ダイナミッ クリンカは,より大きいrevision番号を選択します.
libtoolのバージョン管理システムを使用したい場合,リンクモード (see section リンクモード)で,`-version-info'フラグを使用して,libtool にバージョン情報を指定する必要があります.
このフラグは,`current[:revision[:age]]'の形式 の引数を受け入れます.そして,`-version-info 3:12:1'を渡すと, currentを3,revisionを12,そしてageを1に設定します.
revisionやageが省略された場合,デフォルトは0になります.ま た,ageはcurrentインターフェース番号以下にする必要があるこ とに注意してください.
ライブラリバージョン情報を更新する助けとなる規則の集合は,以下のように なります.
パッケージのリリース番号に対応するように,インターフェース番号を設定す る試みは決してしないでください.これは,ライブラリバー ジョンの目的の誤解を促進する悪習にすぎません.その代わり, `-release'フラグ(see section リリース情報の管理)を使用しますが,パッケー ジが他のリリースとバイナリ互換でないことを警告されます.
プログラムをライブラリにリンクしたいユーザに明確になるように,パッケー ジリリース名を共有ライブラリに符号化したいこともよくあります.この便利 さは,特にGNU/Linuxで使用されます.
trick$ ls /usr/lib/libbfd* /usr/lib/libbfd.a /usr/lib/libbfd.so.2.7.0.2 /usr/lib/libbfd.so trick$
`trick'として,`/usr/lib/libbfd.so'は `libbfd.so.2.7.0.2' へのシンボリックリンクで,それは `binutils-2.7.0.2'の一部として配布されています.
ライブラリインターフェースは,リリース番号のように,滅多に同時に変更さ れず,ライブラリ接尾子はすべてのプラットフォームを跨り,すべて同じでは ないので,残念ながらこの便利さはlibtoolのライブラリバージョンの情報の 考えと直接衝突します.
そのため,両方の見方に適応するため,`-version-info'を使用したくな いライブラリに対し,リリース情報を設定するにあたり,`-release'フ ラグを使用することができます.`libbfd'の例では,libtoolが使用する 次のリリースは,`-release 2.9.0'でビルドされるべきで,それは, GNU/Linuxで,以下のファイルを生成します.
trick$ ls /usr/lib/libbfd* /usr/lib/libbfd-2.9.0.so /usr/lib/libbfd.a /usr/lib/libbfd.so trick$
この場合,`/usr/lib/libbfd.so'は`libbfd-2.9.0.so'へのシンボ リックリンクです.これは`binutils-2.9.0'を扱っているユーザにとっ て,バージョン情報のlibtoolの考えに妥協することなく,明白になります.
このオプションはライブラリ名を編集することに注意し,過去のライブラリリ リースとのバイナリ互換を壊したくない場合は使用しないでください.一般的 に,パッケージの内部ライブラリや,大変頻繁に変更されるインターフェース を持つ物に対してのみ`-release'を使用してください.
Go to the first, previous, next, last section, table of contents.