実行時リンカーがプログラムのメモリーセグメントを作成するとき、依存性は、プログラムのサービスを提供するためにどの共有オブジェクトが必要であるかを示します。 参照された共有オブジェクトとそれが依存するものを繰り返し結合することによって、実行時リンカーは完全なプロセスイメージを生成します。
共有オブジェクトが依存性リストにおいて複数回参照されるときでも、実行時リンカーはこの共有オブジェクトをプロセスに 1 回だけ結合します。
動的実行プログラムのリンク編集中に、1 つまたは複数の共有オブジェクトが明示的に参照されます。これらのオブジェクトは、依存関係として動的実行プログラム内に記録されます。
実行時リンカーは、最初にこの依存情報を見つけ、これを使用して関連オブジェクトの検索および読み込みを行います。これらの依存関係は、実行プログラムのリンク編集中に参照された順番で処理されます。
動的実行プログラムの依存関係がすべて読み込まれると、これらの依存関係も読み込まれた順番に検査され、追加の依存関係が配置されます。この処理は、すべての依存関係の配置と読み込みが完了するまで続きます。この技術の結果、すべての依存関係が幅優先順になります。
デフォルトでは、実行時リンカーが、依存関係の検出場所として認識しているのは、32 ビットの依存関係の場合は /usr/lib、64 ビットの依存関係の場合は /usr/lib/64 という標準的なディレクトリだけです。 単純なファイル名で指定された依存関係には、このディレクトリ名が接頭辞として付き、この接頭辞が付いたパス名は、実際のファイルを配置する場合に使用されます。
動的実行プログラムまたは共有オブジェクトの実際の依存関係は、ldd(1) を使用して表示できます。たとえば、ファイル /usr/bin/cat には次のような依存関係があります。
$ ldd /usr/bin/cat libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 |
ファイル /usr/bin/cat は、依存関係を持つか、またはファイル libc.so.1 と libdl.so.1 が必要です。
ファイル内に記録された依存関係は、ファイルの .dynamic セクションと NEEDED タグの付いたエントリの参照を表示する dump(1) コマンドを使用して検査できます。次の例では、上記の ldd(1) の例で表示された依存関係 libdl.so.1 は、ファイル /usr/bin/cat 内に記録されません。ldd(1) は、指定されたファイルの「すべての」依存関係を示していて、libdl.so.1 は、実際に /usr/lib/libc.so.1 の依存関係にあります。
$ dump -Lvp /usr/bin/cat /usr/bin/cat: [INDEX] Tag Value [1] NEEDED libc.so.1 ......... |
上記の dump(1) の例では、依存関係は単純なファイル名として表示されています。つまり、ファイル名に「/」が含まれていません。単純なファイル名を使用することは、実行時リンカーが、一連の規則に従って必要なパス名を生成する場合に必要です。「/」が組み込まれたファイル名は、そのまま使用されます。
単純なファイル名の記録は、標準的な、依存関係を記録する最も柔軟性の高いメカニズムです。リンカーに -h オプションを指定すると、依存関係内の単純な名前が記録されます。命名規約 および 共有オブジェクト名の記録 を参照してください。
通常、依存関係は、/usr/lib あるいは /usr/lib/64 以外に配布されます。動的実行プログラムまたは共有オブジェクトが、他のディレクトリに依存関係を配置する必要がある場合、実行時リンカーは、明示的に、このディレクトリを検索するように指示されます。
追加の検索パスを実行時リンカーに指示する場合は、動的実行プログラムまたは共有オブジェクトのリンク編集中に、「実行パス」を記録する方法をお勧めします。この情報の記録方法の詳細については、実行時リンカーが検索するディレクトリ を参照してください。
実行パスの記録は、dump(1) を使用して表示し、RUNPATH タグの付いたエントリを参照できます。次の例では、prog は libfoo.so.1 上に依存関係を持っています。実行時リンカーは、デフォルトロケーション/usr/lib を調べる前に、ディレクトリ /home/me/lib と/home/you/lib を検索する必要があります。
$ dump -Lvp prog prog: [INDEX] Tag Value [1] NEEDED libfoo.so.1 [2] NEEDED libc.so.1 [3] RUNPATH /home/me/lib:/home/you/lib ......... |
実行時リンカーの検索パスに追加するもう 1 つの方法は、環境変数 LD_LIBRARY_PATH
を設定する方法です。この環境変数は、プロセスの始動時に 1 度分析され、コロンで区切られたディレクトリのリストに設定できます。実行時リンカーは、このリストに設定したディレクトリを、指定された実行パスまたはデフォルトのディレクトリよりも前に検索します。
これらの環境変数は、アプリケーションを強制的にローカルな依存関係に結合するといったデバッグの目的に適しています。次の例では、上記の例のファイル prog は、現在の作業ディレクトリ内で検出された libfoo.so.1 に結合されます。
$ LD_LIBRARY_PATH=. prog |
LD_LIBRARY_PATH
環境変数の使用は、実行時リンカーの検索パスに影響する一時的なメカニズムとしては有用ですが、製品版ソフトウェアの場合は大きな支障があります。この環境変数を参照できる動的実行プログラムは、その検索パスを拡張させます。これにより、全体のパフォーマンスが低下する場合があります。また、環境変数の使用 と 実行時リンカーが検索するディレクトリ で示したように、LD_LIBRARY_PATH
環境変数はリンカーに影響を及ぼします。
たとえば、64 ビットの実行プログラムに 渡された検索パスと同名の 32 ビットライブラリが存在する環境 (またはその逆) が、プロセスに継承されたとします。このような場合、実行時リンカーは一致しない 32 ビットライブラリを拒否し、有効な 64 ビットと一致するライブラリを検出して、検索パスの処理を続けます。一致するものが見つからない場合には、エラーメッセージが表示されます。このエラーを詳細に監視するには、LD_DEBUG
環境変数を設定して、ファイルのトークンを取り込みます。デバッギングライブラリを参照してください。
$ LD_LIBRARY_PATH=/usr/bin/64 LD_DEBUG=files /usr/bin/ls ... 00283: file=libc.so.1; needed by /usr/bin/ls 00283: 00283: file=/usr/lib/64/libc.so.1 rejected: ELF class mismatch: \ 00283: 32-bit/64-bit 00283: 00283: file=/usr/lib/libc.so.1 [ ELF ]; generating link map 00283: dynamic: 0xef631180 base: 0xef580000 size: 0xb8000 00283: entry: 0xef5a1240 phdr: 0xef580034 phnum: 3 00283: lmid: 0x0 00283: 00283: file=/usr/lib/libc.so.1; analyzing [ RTLD_GLOBAL RTLD_LAZY ] ... |
依存関係が配置できない場合は、ldd(1) により、オブジェクトが検出できないことが表示されます。アプリケーションを実行しようとすると、実行時リンカーから該当するエラーメッセージが表示されます。
$ ldd prog libfoo.so.1 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 $ prog ld.so.1: prog: fatal: libfoo.so.1: open failed: No such file or directory |
実行時リンカー (/usr/lib または /usr/lib/64) によって使用されるデフォルトの検索パスは、crle(1) ユーティリティによって作成される実行時構成ファイルを使用して管理できます。このファイルは、正しい実行パスで作成されなかったアプリケーションについて検索パスを設定する場合に便利です。
構成ファイルのデフォルトの場所は、/var/ld/ld.config (32 ビットアプリケーションの場合) または /var/ld/64/ld.config (64 ビットアプリケーションの場合) で、システム上の、それぞれのタイプのアプリケーションすべてに影響します。構成ファイルはこれ以外の場所にも作成でき、実行時リンカーの LD_CONFIG 環境変数を使用してこれらのファイルを選択できます。後者の方法は、構成ファイルをデフォルトの場所にインストールする前にテストする場合に便利です。
実行時リンカーは、実行パス (DT_RUNPATH または DT_RPATH)、フィルタ (DT_FILTER)、または補助フィルタ (DT_AUXILIARY) 内で使用される場合は、ストリングトークン $ISALIST を置換します。
$ISALIST – このプラットフォームで実行可能なネイティブの命令セットに展開する (isalist(1) マニュアルページを参照)。このトークンを含むパス名は、使用可能な各命令セットに置き換えられる。このトークンの展開については、命令セット固有の共有オブジェクト を参照。
上記で指定されたパス内あるいは依存関係 (DT_NEEDED) エントリ内で実行時リンカーが使用されると、その実行時リンカーは次のストリングトークンを置き換えます。
$ORIGIN – オブジェクトの読み込み元ディレクトリを指定する。このトークンは通常、単独のバンドルされていないパッケージ内に依存関係を配置する場合に使用される。このトークンの展開については、関連する依存関係の配置 を参照。
$OSNAME – オペレーティングシステムの名前に展開する (uname(1) マニュアルページの -s オプションを参照)。このトークンの展開については、プラットフォーム固有の共有オブジェクト を参照。
$OSREL – オペレーティングシステムのリリースに展開する (uname(1) マニュアルページの -r オプションを参照)。このトークンの展開については、プラットフォーム固有の共有オブジェクト を参照。
$PLATFORM – 現在のマシンの現在のプロセッサタイプに展開する (uname(1) マニュアルページの -i オプションを参照)。このトークンの展開については、プラットフォーム固有の共有オブジェクト を参照。