8. ライブラリ内部の依存性

定義では，すべての共有ライブラリシステムは，シンボル解決が実行時まで延 期されるように，実行形式をライブラリに依存させる方法を提供します．

ライブラリ内部の依存性は，他のライブラリに依存するライブラリにあ ります．例えば，libtoolライブラリ`libhello'がcos関数を使用 する場合，それは`libm'に対するライブラリ内部の依存性があり，数学 ライブラリがcosを実装しています．

共有ライブラリシステムには，内部で一貫した方法で，この機能を提供するも のもあります．これらのシステムは，潜在的に無限長の依存性の連鎖を認めま す．

しかし，ほとんどの共有ライブラリのシステムは，単一レベルの依存のみを認 めるという制限があります．これらのシステムでは，プログラムは共有ライブ ラリに依存しますが，共有ライブラリは他の共有ライブラリに依存しません．

あらゆる事象で，ライブラリ内部の依存性を宣言するため，libtoolは単純な メカニズムを提供します．独自のライブラリに依存するすべてのライブラリ `libname'に対しライブラリを作成するとき，対応する -lnameオプションをリンク行に単純に加えます．`libm'に 依存する`libhello'の例をビルドしてみます．

burger$ libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
                -rpath /usr/local/lib -lm
burger$

プログラムを`libhello'に対しリンクするとき，`-l'オプションを 再び指定する必要はありません．必要なライブラリがすべて見つかることを保 証するため，libtoolがそれを行います．この制約は，スタティックライブラ リシステムと，単純なダイナミックライブラリシステムとの互換性を保つため に必要です．

AIXのように，この柔軟性さえ許可されないプラットフォームもあります．共 有ライブラリをビルドするため，それは完全に自己内蔵型である必要があり (すなわち，`.lo'ファイルや`-l'で指定されたライブラリでシンボ ルが見つかるもののみを参照する)，-no-undefinedフラグを指定する必 要があります．デフォルトで，libtoolはこの種のプラットフォームではスタ ティックライブラリのみをビルドします．

1.2以前のlibtoolのリリースのコードにおける，単純に考えられたライブラリ 内部の依存性の追跡は，ライブラリを他のライブラリとリンクすることが可能 なときが明白でないため，それが利用ができず，複雑な異常終了が発生します． この概念のより複雑な実装は，リリース1.3の前に再導入されましたが， libtoolがサポートするすべてのプラットフォームに移植されませんでした． デフォルトで，保守的な動作は，ライブラリが他のライブラリとリンクするこ とを避け，プログラムがリンクされるときのみに，その内部依存性が導入され ます．