付録 A リンカーのクイックリファレンス

概要

この項では、簡単な概要を記載してあります。すなわち、この項は、最も一般的に使用されるリンカーのシナリオの「虎の巻」です (リンカーによって生成される出力モジュールの種類の紹介は、「リンク編集」を参照)。

ここに記載された例では、コンパイラドライバ cc(1) に提供されるリンカーのオプションを示しています。これは、リンカーを起動させる、最も一般的な機構です (「コンパイラドライバを使用する」を参照)。

リンカーは、入力ファイルの名前によって動作を変えることはありません。各ファイルは、開かれ、ファイルが必要とする処理の種類を判別するために検査が行われます (「入力ファイルの処理」を参照)。

libx.so の命名規約に従って命名された共有オブジェクトと、libx.a の命名規約に従って命名されたアーカイブライブラリは、-l オプションを使用して指定できます (「ライブラリの命名規約」を参照)。これにより、-L オプションを使用して指定できる検索パスに、より柔軟性を持たせることができます (「リンカーが検索するディレクトリ」を参照)。

リンカーは、基本的には、「静的」または「動的」の 2 つの方法のうちのいずれかで稼動します。

静的方法

この方法は、-dn オプションが使用された場合に選択されます。また、このモードを使用すると、再配置可能オブジェクトと静的実行プログラムを作成できます。この場合、再配置可能オブジェクトとアーカイブライブラリの入力形式だけが受け入れられます。-l オプションを使用すると、アーカイブライブラリが検索されます。

再配置可能オブジェクトの作成

• 次のように、-dn オプションと -r オプションを使用する

$ cc -dn -r -o temp.o file1.o file2.o file3.o .....

静的実行プログラムの作成

静的実行プログラムの使用は制限されています。静的実行プログラムには、通常、プラットフォーム固有な実装に依存した情報などが組み込まれ、これにより、他のプラットフォーム上で実行プログラムを実行することが制限されます。また、ほとんどの Solaris ライブラリは、dlopen(3DL) や dlsym(3DL) などの動的リンク機能に依存しています (「追加オブジェクトの読み込み」を参照)。これらの機能は、静的実行プログラムでは使用できません。

• -dn オプションは、次のように -r オプションを「指定せずに」使用する

$ cc -dn -o prog file1.o file2.o file3.o .....

-a オプションを使用して、静的実行プログラムの作成を指示できます。そして、-dn を指定して、-r を指定しない場合、-a が暗黙指定されます。

動的方法

これは、リンカーの標準の動作方法です。-dy オプションで明示的に指定することもできますが、-dn オプションを使用しない場合には、暗黙指定されます。

この場合、再配置可能オブジェクト、共有オブジェクト、およびアーカイブライブラリを指定できます。-l オプションを使用すると、ディレクトリ検索が実行されます。ここで、各ディレクトリは、共有オブジェクトを見つけるために検索され、そのディレクトリで共有オブジェクトが見つからない場合は、次にアーカイブライブラリが検索されます。-B static オプションを使用すると、アーカイブライブラリの検索だけに限定されます。(「共有オブジェクトとアーカイブとの混合体へのリンク」を参照)。

共有オブジェクトの作成

• -G オプションを使用する (-dy は省略時には暗黙指定されるため、指定する必要はない)

• 入力再配置可能オブジェクトは、位置非依存のコードから作成する必要がある。-z text オプションを使用して、この必要条件を実行する (「位置に依存しないコード」を参照)

• 共有オブジェクトの公開インタフェースを確立する。共有オブジェクトの外から見える大域シンボルを定義し、それ以外のすべてのシンボルはローカル範囲に隠薮する。これは、-M オプションとともに mapfile を指定することによって定義できる。詳細は、付録 B 「バージョンアップの手引き」 を参照

• 将来アップグレードに対応できるように、共有オブジェクトにはバージョンを含む名前を使用する (「バージョンアップファイル名の管理」を参照)

• 生成される共有オブジェクトが他の共有オブジェクトに依存している場合は、-z lazyload オプションを使用してレイジー読み込みを指定する (「動的依存関係のレイジーローディング」を参照)

• 生成される共有オブジェクトが他の共有オブジェクトと依存関係があり、これらの共有オブジェクトが 32 ビットオブジェクト用 /usr/lib または 64 ビットオブジェクト用 /usr/lib/64 に存在しない場合は、-R オプションを使用して、そのパス名を出力ファイル内に記録する (「依存関係を持つ共有オブジェクト」を参照)

• 自己完結型の共有オブジェクトは、最も柔軟性が高く、オブジェクトが必要とするものすべてを自身が提供している場合に作成される。-z defs オプションを使用して、自己完結していることを確認する (「共有オブジェクトの生成」を参照)

• すべての再配置を 1 つの .SUNW_reloc セクションに配置することによって、再配置処理を最適化する。-z combreloc オプションを使用する

• 不必要な依存性を排除する。-z ignore オプションを使用するとリンカーは、参照されたオブジェクトに対する依存性だけを記録する

• このオブジェクトや関連する依存関係で割り込みシンボルが使用されない場合は、-B direct を使って直接結合情報を確立する (「外部結合」を参照)。

次に、説明したオプションを組み合わせた例を示します。

$ cc -c -o foo.o -Kpic foo.c
$ cc -M mapfile -G -o libfoo.so.1 -z text -z defs -B direct -z lazyload ¥
-z combreloc -z ignore -R /home/lib foo.o -L. -lbar -lc

• 生成される共有オブジェクトが、他のリンク編集への入力として使用される場合、-h オプションを使用して、その中に共有オブジェクトの実行名を記録する (「共有オブジェクト名の記録」を参照)

• 共有オブジェクトを、バージョンを含まない名前のファイルにシンボリックリンクして、その共有オブジェクトをコンパイル環境でも使用できるようにする (「バージョンアップファイル名の管理」を参照)

次の例は、説明したオプションを組み合わせたものです。

$ cc -M mapfile -G -o libfoo.so.1 -z text -z defs -B direct -z lazyload ¥
-z combreloc -z ignore -R /home/lib -h libfoo.so.1 foo.o -L. -lbar -lc
$ ln -s libfoo.so.1 libfoo.so

• 共有オブジェクトのパフォーマンスへの影響を考慮する。共有性を最大限にし (「共有可能性の最大化」を参照) ページング回数を最小にする (を参照)。特にシンボル再配置を最小限にすることにより、再配置の無駄を削減し (「共有オブジェクトのプロファイリング」を参照)、関数インタフェースを経由して、データにアクセスできるようにする (「コピー再配置」を参照)

動的実行プログラムの作成

• -G オプションと -dn オプションを使用しない

• 生成される共有オブジェクトが他の共有オブジェクトに依存している場合は、-z lazyload オプションを使用してレイジー読み込みを指定する (「動的依存関係のレイジーローディング」を参照)

• 生成される動的実行プログラムが他の共有オブジェクトと依存関係があり、これらの共有オブジェクトが 32 ビットオブジェクト用 /usr/lib または 64 ビットオブジェクト用 /usr/lib/64 に存在しない場合は、-R オプションを使用してパス名を出力ファイル内に記録する (「実行時リンカーが検索するディレクトリ」を参照)

• -B direct を使って直接結合情報を確立する (「外部結合」を参照)。

次の例は、説明したオプションを組み合わせたものです。

$ cc -o prog -R /home/lib -z ignore -z lazyload -B direct -L. ¥
-lfoo file1.o file2.o file3.o .....