LD

索引

名称

索引

書式

索引

解説

ld は、リンク処理を明示的かつ統合的に制御するために、 AT&T のリンクエディタコマンド言語の文法の上位互換セットで 記述されたリンカコマンド言語のファイルを受け付けます。

このマニュアルページではコマンド言語についてふれません。 コマンド言語の詳細と GNU リンカの別の側面からの詳細については "info" の ld の項、またはマニュアル ld: the GNU linker を参照してください。

このバージョンの ld は、オブジェクトファイルの操作に汎用の BFD ライブラリを使用します。 これによって ld は、多くの異なった形式 --- 例えば COFF や "a.out" のようなオブジェクトファイル --- の読み込み、結合、書き込みが出来るようになっています。 異なる形式のファイルを一緒にリンクして、 任意の利用可能なオブジェクトファイルを生成できます。

その柔軟性の他にも、GNU リンカは、診断情報の提供という点で 他のリンカよりも役に立ちます。 多くのリンカは、エラーを起こした時点で即座に実行を中断してしまいますが、 ld は可能な限り実行を続けるので、他のエラーも突き止めることが できます。 (また、場合によっては、エラーにもかかわらず出力ファイルを生成します)。

GNU リンカ ld は、広い範囲の各種状況に対応すること、 そして他のリンカとの互換性をできるだけ維持することを目指しています。 そのため、その動作を制御するための多くの選択肢があります。  

索引

オプション

        ld -o <output> /lib/crt0.o hello.o -lc

これは、"/lib/crt0.o" と "hello.o"、そして 標準で検索されるディレクトリにあるライブラリ "libc.a" を リンクして、output という名前のファイルを生成することを ld に 対して指示しています。

ld に対するいくつかのコマンドラインオプションは、コマンドラインの どこででも指定できます。 しかし、ファイルを参照する -l や -T のようなオプションは、 オブジェクトファイルやその他のファイルオプションに関連しており、 コマンドライン中にオプションが現れた時点でファイルを読みます。 ファイルを取らないオプションを異なる引数を指定して繰返しても、 それ以上影響がないか、もしくは (コマンドライン上で左にある) それまでの指定を上書きします。 2 回以上指定しても意味のあるオプションは、以下の説明の中で記述されています。

オプション引数ではないものは、一緒にリンクされるオブジェクトファイルか アーカイブです。 それらは、オプションとそのオプションの引数の間に入らない限り、 コマンドラインオプションの前に置いても、後ろに置いても、 混ぜて指定しても構いません。

通常、リンカは少なくとも 1 つのオブジェクトファイルを指定して 起動されますが、-l や -R を用いて、または スクリプトコマンド言語使って、他のバイナリ形式の入力ファイルを 指定することができます。 バイナリ入力ファイルが全く指定されなかった場合、 リンカは何も出力をせず、No input files というメッセージを出します。

リンカがオブジェクトファイルの形式を認識できなかった時は、 それをリンカスクリプトと仮定します。 このように指定されたスクリプトは、リンクに使われる主リンカスクリプト (デフォルトのリンカスクリプト、もしくは -T で指定されたスクリプト) に 追加されます。 この機能により、一見オブジェクトファイルもしくはアーカイブに見えるが、 実際は単にシンボル値を定義しているだけだったり、 "INPUT" や "GROUP" を使って 他のオブジェクトを読み込んでるだけのファイルをリンクすることができます。 このように指定されたスクリプトは、主リンカスクリプトに 単に追加されるだけということに注意してください。 デフォルトのリンカスクリプトを完全に置き換える場合は、 -T オプションを使ってください。

1 文字の名前を持つオプションの引数は、間に空白が入らずに オプション文字に続くか、その引数が必要なオプションのすぐ後に、 独立した引数として与えられるかしなければなりません。

複数文字の名前を持つオプションは、 1 つ、または 2 つのダッシュの どちらの後に続いても構いません。 例えば、-trace-symbol と --trace-symbol は等価です。 このルールには 1 つだけ例外があることに注意してください。 小文字の 'o' で始まる複数文字のオプションは、 2 つのダッシュの後にしか続きません。 これは、-o オプションとの混乱を少なくするためです。 ですから、例えば -omagic は出力ファイル名を magic とするのに対して、--omagic は出力に NMAGIC フラグを設定します。

複数文字のオプションへの引数は、等号記号がオプションとの間に入るか、 その引数を必要とするオプションのすぐ後に、 独立した引数として与えられるかしなければなりません。 例えば、--trace-symbol foo と --trace-symbol=foo は 等価です。 複数文字のオプションを、一意に定まるように省略しても、受け付けられます。

リンカがコンパイラドライバ (例えば gcc) によって間接的に 起動される場合、すべてのリンカのコマンドラインオプションは、 -Wl, (もしくは特定のコンパイラドライバの適切なオプション) に続いて以下のように指定されなければなりません:

          gcc -Wl,--startgroup foo.o bar.o -Wl,--endgroup

これは重要です。 というのも、このようにしないと、コンパイラドライバプログラムは 何も言わずにリンカオプションを落してしまい、リンクが正しく 行われなくなってしまうからです。

以下は、GNU リンカが受け入れる一般的なコマンドラインスイッチの 一覧です:

-akeyword

このオプションは、HP/UX との互換性のためにサポートされています。 keyword 引数は、文字列 archive, shared または default のどれかでなければなりません。 -aarchive は、機能的には -Bstatic と等価であり、 残りの 2 つの keyword は、機能的に -Bdynamic と等価です。 このオプションは何度でも使うことができます。

-Aarchitecture

--architecture=architecture

現在リリースされている ld では、このオプションは Intel 960 ファミリのアーキテクチャでのみ使われます。 そのような ld の構成では、architecture 引数は、 960 ファミリの特定のアーキテクチャを指定し、いくつかの保護手段を有効にし、 アーカイブライブラリの検索パスを修正します。

将来の ld のリリースでは、他のアーキテクチャファミリでも 同様の機能をサポートするかもしれません。

-b input-format

--format=input-format

ld は、1 種類以上のオブジェクトファイルをサポートするように 構成することができます。 もし ld がそのように構成されているなら、-b オプションで 入力するオブジェクトファイルのバイナリ形式を指定することができます。 その入力ファイルは、コマンドライン上でこのオプションに続けて指定します。 たとえ ld が、他のオブジェクト形式をサポートするように 設定されていても、通常このオプションを指定する必要はありません。 というのも、ld は、それぞれマシン上で最も一般的な形式が デフォルトの入力形式であると期待するよう設定されているからです。 input-format はテキスト文字列で、BFD ライブラリで サポートされている特定の形式名です (objdump -i で、使用可能なバイナリ形式名のリストが得られます)。

ファイルを通常でないバイナリ形式とリンクしたい場合に、 このオプションを使うことができます。 (異なる形式のオブジェクトファイルとリンクする時に) 同様に -b で明示的に形式を切り替えられます。 その場合は -b input-format を特定の形式の オブジェクトファイルの各グループの前で指定します。

デフォルトの形式は、環境変数 "GNUTARGET" から 取得されます。

スクリプトから入力形式を指定する事もでき、 その場合はコマンド "TARGET" を使います。

-c MRI-commandfile

--mri-script=MRI-commandfile

MRI 製のリンカとの互換性のため、ld は、 GNU ld ドキュメントの MRI 互換スクリプトファイルの章に 記述されているもう一つの制限されたコマンド言語で書かれた スクリプトファイルを受け付けます。 オプション -c で MRI スクリプトファイルを導入した場合は、 -T オプションを用いることで、汎用目的の ld スクリプト言語で 書かれたリンカスクリプトを走らせることができます。 MRI-commandfile がなかった場合、ld は、-L で指定された すべてのディレクトリを探します。

-d

-dc

-dp

これらの 3 つのオプションは等価です。 他のリンカとの互換性のために複数の形式がサポートされています。 再配置可能なファイルを出力するように (-r によって) 指定された場合でも、コモンシンボルに空間を割り当てます。 スクリプトコマンドの "FORCE_COMMON_ALLOCATION" も 同じ効果を持ちます。

-e entry

--entry=entry

プログラムの実行開始点を示す明示的なシンボルとして、 デフォルトのエントリポイントの代わりに entry を使用します。 シンボル entry がなかった場合、リンカは entry を 数字として解釈しようと試み、それを開始番地として使います (数字は基数を 10 として解釈されます。 先頭についた 0x は 16 を基数とすることを表し、0 は 8 を基数とすることを表します)。

-E

--export-dynamic

動的にリンクされた実行ファイルを作成する時に、すべてのシンボルを 動的シンボルテーブルに加えます。 動的シンボルテーブルは、実行時に動的オブジェクトから見えるシンボルの テーブルです。

もしこのオプションを使用しなかった場合、通常、 動的シンボルテーブルには、リンク中に指定されたいくつかの 動的オブジェクトから参照されるシンボルのみが含まれます。

他の動的オブジェクトではなく、そのプログラムで定義されているシンボルを 参照し返す必要のある動的オブジェクトを "dlopen" で ロードする場合は、おそらくプログラム自身をリンクする時にこのオプションを 使う必要があるでしょう。

出力形式がサポートしていた場合、バージョンスクリプトを使って、 どのシンボルを動的シンボルテーブルに追加すべきかを制御できます。 @ref{VERSION} 中の --version-script の記述を 参照してください。

-EB

ビッグエンディアンのオブジェクトをリンクします。 これはデフォルトの出力形式に影響します。

-EL

リトルエンディアンのオブジェクトをリンクします。 これはデフォルトの出力形式に影響します。

-f

--auxiliary name

ELF の共有オブジェクトを生成する際に、内部の DT_AUXILIARY フィールドに、指定した name を設定します。 これは、共有オブジェクトのシンボルテーブルを、共有オブジェクト name のシンボルテーブルに適用する補助のフィルタとして使う事を、 動的リンカに対して指示します。

後からこのフィルタオブジェクトに対してプログラムをリンクした場合、 そのプログラムを実行した時に、動的リンカは DT_AUXILIARY フィールドを見ます。 動的リンカがフィルタオブジェクトからのシンボルを解決する場合は、 共有オブジェクト name の中に定義があるかどうかをまずチェックします。 もしそれがあった場合は、フィルタオブジェクト中の定義の代わりに使用されます。 共有オブジェクト name は、存在しなくても構いません。 このようにして共有オブジェクト name は、おそらくデバッギングや マシン特有のパフォーマンスといったある機能の別の実装を提供するために 使用できます。

このオプションは 2 回以上指定されても構いません。 DT_AUXILIARY エントリは、コマンドラインに現れた順番に生成されます。

-F name

--filter name

ELF の共有オブジェクトを生成する際に、内部の DT_FILTER フィールドに、指定した name を設定します。 これは、共有オブジェクトのシンボルテーブルを、共有オブジェクト name のシンボルテーブルに適用するフィルタとして使う事を、 動的リンカに対して指示します。

後からこのフィルタオブジェクトに対してプログラムをリンクした場合、 そのプログラムを実行した時に、動的リンカは DT_FILTER フィールドを見ます。 動的リンカは、通常のようにフィルタオブジェクトのシンボルテーブルに従って シンボルを解決しますが、実際には共有オブジェクト name 中に見つかった 定義にリンクします。 このようにしてフィルタオブジェクトは、オブジェクト name によって 提供されたシンボルのサブセットを選択するのに使用できます。

いくつかの古いリンカは、コンパイルツールチェーンを通して、 -F オプションを、入力および出力オブジェクトファイル両方の形式を 指定するために使っていました。 GNU リンカは、この目的に別のメカニズムを用いています。 それは -b, --format, --oformat オプションや、 リンカスクリプト中の "TARGET" コマンド、 そして "GNUTARGET" 環境変数です。 GNU リンカは、ELF 共有オブジェクトを作らない時には、 -F オプションを無視します。

-fini name

ELF の実行形式もしくは共有オブジェクトを生成する際、 関数のアドレスに DT_FINI を設定することにより、 実行形式もしくは共有オブジェクトがアンロードされる時に NAME を呼びます。 デフォルトでは、リンカは "_fini" を、呼ぶべき関数として 使用します。

-g

無視されます。 これは他のツールとの互換性のために提供されています。

-Gvalue

--gpsize=value

GP レジスタを使用して最適化されるオブジェクトの最大サイズを size に設定します。 これは、大きいオブジェクトと小さいオブジェクトを異なるセクションに 配置することをサポートしている MIPS ECOFF のような オブジェクトファイル形式の場合のみ意味を持ちます。 他のオブジェクトファイル形式の場合は無視されます。

-hname

-soname=name

ELF の共有オブジェクトを生成する際に、内部の DT_SONAME フィールドに、指定した name を設定します。 実行形式が DT_SONAME フィールドを持つ共有オブジェクトと リンクされると、実行形式が実行される時に、動的リンカは リンカに与えられたファイル名を使う代わりに DT_SONAME フィールドで 指定された共有オブジェクトをロードしようとします。

-i

インクリメンタルリンクを行います (オプション -r と同じです)。

-init name

ELF の実行形式もしくは共有オブジェクトを生成する際、 関数のアドレスに DT_INIT を設定することにより、 実行形式もしくは共有オブジェクトがロードされる時に NAME を呼びます。 デフォルトでは、リンカは "_init" を、呼ぶべき関数として 使用します。

-larchive

--library=archive

アーカイブファイル archive を、リンクすべきファイルのリストに 追加します。 このオプションは、何度指定しても構いません。 ld は、archive が指定されるたびに "libarchive.a" を自身のパスリストから探します。

共有ライブラリをサポートするシステムでは、ld は、".a" 以外のサフィックスを持つライブラリも探すことがあります。 特に ELF や SunOS システムでは、ld は、".a" というサフィックスを持つライブラリを探す前に、".so" という サフィックスを持つライブラリをディレクトリから探します。 慣習により、".so" サフィックスは共有ライブラリを示します。

リンカは、コマンドラインで指定されたその場所でのみ、 1 回だけアーカイブを検索します。 もしそのアーカイブが、それまでにコマンドラインに現れたオブジェクトでは 定義していないシンボルを定義していた時は、リンカは、そのアーカイブから 適切なファイルを取り込みます。 しかし、コマンドラインに後から現れたオブジェクトに含まれる 未定義シンボルによって、リンカがアーカイブを再度検索することはありません。

アーカイブを複数回検索するようリンカに強制する方法は、 -( オプションを参照してください。

同じアーカイブをコマンドライン上に複数回指定しても構いません。

この種のアーカイブ検索は、Unix のリンカでは普通です。 しかし AIX 上で ld を使用する場合、AIX リンカとは 異なった動作をするので注意が必要です。

-Lsearchdir

--library-path=searchdir

パス searchdir を、ld がアーカイブライブラリや ld の 制御スクリプトを検索するのに使用するパスのリストに追加します。 このオプションは、何度指定しても構いません。 ディレクトリは、コマンドライン上で指定された順に検索されます。 コマンドライン上で指定されたディレクトリは、デフォルトのディレクトリの 前に検索されます。 すべての -L オプションは、オプションの出現した順番によらず、 すべての -l オプションに適用されます。

searchdir が "=" で始まる場合、 "=" は sysroot prefix (リンカが構成された際に指定されたパス) により置き換えられます。

(-L で指定されない) デフォルトの検索パスの組は、 ld がどのエミュレーションモードを使っているか、 そして場合によってはどのように構成されたかに依存します。

パスは、リンクスクリプト中で "SEARCH_DIR" コマンドを用いても指定できます。 この方法で指定されたディレクトリは、コマンドライン上でリンカスクリプトが 現れた時点で検索されます。

-memulation

emulation リンカをエミュレートします。 --verbose や -V オプションで、利用可能なエミュレーションを リストできます。

-m オプションが指定されていない場合、エミュレーションは、 "LDEMULATION" 環境変数が定義されていれば そこから取得されます。

それ以外の場合、デフォルトのエミュレーションは、リンカがどのように 構成されたかに依存します。

-M

--print-map

リンクマップを標準出力に表示します。 リンクマップは、以下を含むリンクの情報を提供します:

*

オブジェクトファイルとシンボルが、メモリのどこにマップされるか。

*

コモンシンボルがどのように割り当てられたか。

*

リンクに含まれるすべてのアーカイブメンバ、および そのアーカイブメンバを取り込むきっかけとなったシンボル。

-n

--nmagic

セクションのページアラインメントを無効にし、可能であれば 出力に "NMAGIC" と印を付けます。

-N

--omagic

テキストセクションとデータセクションを読み書き可能に設定します。 また、データセグメントのページアラインメントも行いません。 共有ライブラリとのリンクもできなくなります。 出力形式が Unix 形式のマジックナンバをサポートしている場合、 出力に "OMAGIC" と印を付けます。 注意: PE-COFF ターゲットに対して、書き込み可能なテキストセクションは 許されていますが、これは Microsoft が発行している形式仕様には 適合していません。

--no-omagic

このオプションは、-N オプションの持つ効果のほとんどを否定します。 テキストセグメントを読み込み専用とし、データセグメントを強制的に ページアラインメントします。 このオプションは共有ライブラリとのリンクを 有効にしないことに注意して下さい。 共有ライブラリとのリンクのためには、 -Bdynamic を使用して下さい。

-o output

--output=output

output を、ld によって生成されるプログラムの 名前として使用します。 このオプションが指定されなかった場合、a.out という名前が デフォルトで使用されます。 スクリプトコマンドの "OUTPUT" によっても、 出力ファイル名を指定することができます。

-O level

level が 0 より大きい数値であった場合、 ld は出力を最適化します。 これにはとても長い時間がかかりますので、最終的なバイナリの作成時のみ 有効にするべきでしょう。

-q

--emit-relocs

最終的にリンクされた実行形式中に、再配置セクションと内容を残します。 これらの情報は、リンク後の分析・最適化ツールが実行形式を正しく変更するのに 必要となるでしょう。 これは、より大きな実行形式を生成します。

このオプションは、現在 ELF プラットフォームでしか サポートされていません。

-r

--relocatable

再配置可能な出力を生成します。 つまり、ld への入力として利用できる出力ファイルを生成します。 これはよく 部分リンク と呼ばれます。 この副作用として、Unix の標準のマジックナンバをサポートする環境では、 このオプションは出力ファイルのマジックナンバを "OMAGIC" に設定します。 このオプションが指定されなかった場合は、 絶対アドレス値を用いたファイルが生成されます。 C++ プログラムをリンクする場合、 このオプションはコンストラクタへの参照を解決しません。 そのような場合は -Ur を使用してください。

入力ファイルが出力ファイルと同じ形式ではない場合、 部分リンクは、入力ファイルが再配置セクションを全く持たない時のみ サポートされます。 異なった出力形式は、さらなる制限を持つことがあります。 例えば、ある "a.out" ベースの形式は、 入力ファイルが異なった形式であった時には、部分リンクを全くサポートしません。

このオプションは、-i と同じです。

-R filename

--just-symbols=filename

シンボル名やそのアドレスを filename から読み込みますが、 それを再配置したり出力に含めることはしません。 これにより、出力ファイルが他のプログラムで定義されたメモリの絶対位置を シンボルで参照できるようになります。 このオプションは 2 回以上使って構いません。

他の ELF リンカとの互換性のため、-R オプションの後に ファイル名ではなくディレクトリ名が続いた場合、 -rpath オプションとして扱われます。

-s

--strip-all

すべてのシンボル情報を出力ファイルから削除します。

-S

--strip-debug

(すべてのシンボルではなく) すべてのデバッグ用シンボル情報を 出力ファイルから削除します。

-t

--trace

ld が入力ファイルを処理するたびに、入力ファイル名を表示します。

-T scriptfile

--script=scriptfile

scriptfile をリンカスクリプトとして使用します。 このスクリプトは、(追加されるのではなく) ld のデフォルトの リンカスクリプトを置き換えます。 したがって、scriptfile には、出力ファイルを記述するのに必要な すべてのことを指定しなければなりません。 scriptfile がカレントディレクトリに存在しない場合、 "ld" は、すべての -L オプションに続いて 指定されたディレクトリを検索します。 複数の -T オプションは、一つにまとめられます。

-u symbol

--undefined=symbol

強制的に symbol を未定義シンボルとして出力ファイルに含めます。 こうすることによって、例えば標準ライブラリからさらにモジュールを リンクする引き金とすることができます。 異なるオプション引数を持つことで -u を繰返し指定することができ、 未定義シンボルを追加します。 このオプションは、"EXTERN" リンカスクリプトコマンドと 同じです。

-Ur

C++ プログラム以外に対しては、このオプションは -r と同じです。 再配置可能な出力、つまり ld に再度入力可能な出力ファイルを 生成します。 C++ プログラムをリンクする場合、-r とは異なり、 -Ur はコンストラクタへの参照を解決します。 -Ur を使用してリンクされたファイルに対しては、 -Ur を使用できません。 コンストラクタのテーブルが一度生成されると、追加することができないのです。 -Ur は、最後の部分リンクのみに使用するようにして、 その他の場合は -r を使用してください。

--unique[=SECTION]

SECTION に一致した入力セクションごとに、 個別の出力セクションを生成します。 オプションのワイルドカード SECTION 引数がない場合は、 親なし入力セクションごとに、個別の出力セクションを生成します。 親なしセクションとは、リンカスクリプト中に 明示的に記述されていないセクションです。 このオプションは、コマンドライン上で複数回使用できます。 これによって、通常の同名の入力セクションのマージを行わないようにします。 これは、リンカスクリプト中での出力セクションの割り当てを上書きします。

-v

--version

-V

ld のバージョン番号を表示します。 -V オプションは、サポートしているエミュレータの一覧も表示します。

-x

--discard-all

すべてのローカルシンボルを削除します。

-X

--discard-locals

すべての一時的なローカルシンボルを削除します。 ほとんどのターゲットにおいて、それは名前が L で始まる すべてのローカルシンボルです。

-y symbol

--trace-symbol=symbol

リンクされたファイルのうち、symbol が現れるファイル名を表示します。 このオプションは何度でも指定できます。 多くのシステム上では、シンボル名の前にアンダスコアを つける必要があるでしょう。

このオプションは、リンク中に未定義シンボルが発見されたが、 それがどこから参照されているのかがわからない場合に役に立ちます。

-Y path

デフォルトのライブラリ検索パスに path を追加します。 このオプションは、Solaris との互換性のために存在します。

-z keyword

認識されるキーワードは次のとおりです。

combreloc

複数の再配置セクションを結合し、動的シンボル検索キャッシュ処理を 可能にします。

defs

オブジェクトファイル中の未定義シンボルを許しません。 共有ライブラリ中の未定義シンボルは許されます。

initfirst

このオプションは共有オブジェクトを構築しているときにのみ意味があります。 オブジェクトに印を付け、そのオブジェクトの実行時初期化処理が、 他のすべてのオブジェクトがプロセスに導入されるより前に、 同時に生じるようにします。 同様に、そのオブジェクトの実行時終了処理が、 他のすべてのオブジェクトの実行時終了処理が終った後に 生じるようにします。

interpose

シンボルテーブルが主実行形式以外のすべてのシンボルの前に挿入されるように、 オブジェクトに印を付けます。

loadfltr

フィルタが実行時に直ちに処理されるように、オブジェクトに印を付けます。

muldefs

複数回の定義を許可します。

nocombreloc

複数の再配置セクションの結合を無効にします。

nocopyreloc

再配置セクションの複製生成を無効にします。

nodefaultlib

依存関係検索の際に、デフォルトライブラリ検索パスを 無視するように、オブジェクトに印を付けます。

nodelete

実行時にロード解除 (unload) されないように、 オブジェクトに印を付けます。

nodlopen

"dlopen" が適用できなくなるように、 オブジェクトに印を付けます。

nodump

"dldump" によりダンプできなくなるように、 オブジェクトに印を付けます。

now

実行可能ライブラリまたは共有ライブラリを生成するときに、 関数が最初に呼び出されるまで関数呼び出し解決を遅らせるのではなく、 プログラムの実行開始時または、 共有ライブラリが dlopen を使いリンクする際に すべてのシンボルを解決するように動的リンカに教えるために、 ライブラリに印を付けます。

origin

$ORIGIN を含むかもしれないオブジェクトに印を付けます。

他のキーワードは、Solaris との互換性のために無視されます。

-( archives -)

--start-group archives --end-group

archives は、アーカイブファイルのリストを指定します。 これらはファイル名そのものでも、-l オプションでも構いません。

指定されたアーカイブは、新たな未定義参照がなくなるまで繰返し検索されます。 通常、アーカイブは、コマンドラインで指定された順番で 1 回だけ検索されます。 そのアーカイブ中のシンボルが、コマンドライン上の後ろに現れた アーカイブ中のオブジェクトが参照する未定義シンボルを 解決するのに必要な場合、リンカはその参照を解決することができません。 アーカイブをグループ化すると、すべての可能な参照が解決されるまで、 それらのすべてのアーカイブは繰返し検索されます。

このオプションを使用すると、パフォーマンスが大きく落ちます。 これを使うのは、2 つ以上のアーカイブ中で、参照の循環が避けられない 場合のみに使用するのがよいでしょう。

--accept-unknown-input-arch

--no-accept-unknown-input-arch

リンカに対し、アーキテクチャを識別できない入力ファイルを 受け付けるように指示します。 これは、ユーザが自分が何をしているかを理解していて、それでも 未知の入力ファイルをリンクしようとしている場合を想定しています。 リリース 2.14 より前には、こちらの方がリンカのデフォルトの動作でした。 リリース 2.14 以後、これらの入力ファイルが拒否されるようになり、 かつての動作に戻すために、--accept-unknown-input-arch オプションが追加されました。

--as-needed

--no-as-needed

このオプションは、コマンド行で指定した動的ライブラリで --as-needed オプションより後のものの ELF DT_NEEDED タグに影響を与えます。 通常、リンカは コマンドラインで指定した動的ライブラリそれぞれに対し それらが実際に必要かどうかに無関係に DT_NEEDED タグを 追加します。 --as-needed により、通常オブジェクトから何らかの参照を 満たすライブラリにのみ DT_NEEDED タグを付けるようになります。 --no-as-needed によりデフォルトの動作に戻ります。

-assert keyword

このオプションは、SunOS との互換性のために無視されます。

-Bdynamic

-dy

-call_shared

動的ライブラリとリンクします。 これは、共有ライブラリをサポートするプラットフォーム上でのみ 意味を持ちます。 このオプションは、そのようなプラットフォーム上では、 普通デフォルトとなっています。 このオプションに異なる形式があるのは、様々なシステムとの互換性のためです。 このオプションは、コマンド上で何度でも使用することができます。 これは後に続く -l オプションのライブラリ検索に影響します。

-Bgroup

動的セクション中の "DT_FLAGS_1" エントリの "DF_1_GROUP" フラグを設定します。 これによって、動的リンカがこのオブジェクトとその依存関係の検索を グループ内でのみ実行するようになります。 --no-unresolved-symbols=report-all が暗黙に指定されます。 このオプションは、共有ライブラリをサポートする ELF プラットホーム上でのみ意味を持ちます。

-Bstatic

-dn

-non_shared

-static

共有ライブラリをリンクしません。 これは、共有ライブラリをサポートするプラットフォーム上でのみ 意味を持ちます。 このオプションに異なる形式があるのは、様々なシステムとの互換性のためです。 このオプションは、コマンドライン上で何度でも使用することができます。 これは後に続く -l オプションのライブラリ検索に影響します。 このオプションは --unresolved-symbols=report-all も 暗黙のうちに含みます。

-Bsymbolic

共有ライブラリを生成する際に、その共有ライブラリ中に定義があれば、 グローバルシンボルへの参照をその定義に結びつけます。 通常、共有ライブラリをリンクしたプログラムは、 その共有ライブラリ中の定義を上書きできます。 このオプションは、共有ライブラリをサポートする ELF プラットホーム上でのみ意味を持ちます。

--check-sections

--no-check-sections

セクションアドレスが割り当てられた後、それらのアドレスが重なって いないかどうかのチェックをしないようリンカに指示します。 通常、リンカはチェックを行い、重なりを発見した時は 適切なエラーメッセージを出力します。 リンカは、オーバレイセクションのことを知っており、 それを生成することを許可します。 コマンドラインスイッチ --check-sections を使用することで、 デフォルトの動作に戻せます。

--cref

相互参照テーブルを出力します。 リンカマップファイルが生成される場合、 相互参照テーブルはマップファイルに出力されます。 それ以外の場合、標準出力に出力されます。

テーブル形式は、意図的に簡単にしているので、 必要な場合はスクリプトで簡単に処理することができます。 シンボルは、名前でソートされて出力されます。 それぞれのシンボルごとに、ファイル名がリストされます。 シンボルが定義されている場合は、リストの最初のファイルに その定義が含まれています。 残りのファイルは、そのシンボルへの参照を含んでいます。

--no-define-common

このオプションは、コモンシンボルへのアドレス割り当てを抑制します。 スクリプトコマンド "INHIBIT_COMMON_ALLOCATION" は、 同じ効果を持ちます。

--no-define-common オプションは、コモンシンボルへアドレスを 割り当てる判断を、出力ファイルのタイプの選択から切り離します。 このオプションを指定しない場合は、再配置不可の出力タイプによって、 アドレスは強制的にコモンシンボルへ割り当てられます。 --no-define-common を使用することにより、共有ライブラリから 参照されるコモンシンボルは、主プログラムのアドレスのみに割り当てられます。 このオプションは、共有ライブラリ中の重複した未使用領域を削除します。 また、動的シンボル解決するために特殊な検索パスを持つたくさんの 動的モジュールがある場合、間違った重複を解決する際に起こり得る混乱を 防ぎます。

--defsym symbol=expression

expression で指定される絶対アドレスを含んだ グローバルシンボルを、出力ファイルに生成します。 複数のシンボルを定義するために、コマンドライン上で必要な回数だけ このオプションを使用できます。 expression には、限定された形式の算術演算がサポートされてます。 16 進定数や存在するシンボル名が使用でき、 16 進定数やシンボルの加減算に "+" や "-" を 使用できます。 もっと複雑な式が必要であれば、スクリプトからリンカのコマンド言語を 使用することを検討してください。 注意: symbol や等号 (``='')、expression の間に 空白を入れてはいけません。

--demangle[=style]

--no-demangle

これらのオプションは、エラーメッセージやその他の出力に含まれる シンボル名をデマングルするかどうかを制御します。 デマングルする場合、リンカはシンボル名を読みやすい形式で 表現しようと試みます。 つまりリンカは、先頭のアンダスコアがオブジェクトファイル形式で 使用されていた場合、それを取り除き、C++ のマングルされたシンボル名を ユーザが読みやすい名前に変換します。 コンパイラによってマングル形式は異なります。 デマングル形式引数を指定することにより、使用しているコンパイラに対応した デマングル形式を選択できます。 リンカは、環境変数 COLLECT_NO_DEMANGLE が設定されていない限り、 デフォルトでデマングルします。 これらのオプションによって、デフォルトを上書きできます。

--dynamic-linker file

動的リンカの名前を設定します。 これは、動的にリンクされる ELF 実行形式を生成する時のみ 意味があります。 通常は、デフォルトの動的リンカで正しいはずです。 自分が何をしようとしているのかがわかってる場合以外は、 使用しないでください。

--embedded-relocs

このオプションは、GNU コンパイラとアセンブラに -membedded-pic オプションを指定して生成した MIPS の埋め込み PIC コードを リンクする時のみ意味があります。 これを指定すると、リンカはあるテーブルを生成します。 このテーブルは、ポインタの値に静的に初期化されているすべてのデータを、 実行時に再配置するために使われます。 詳細は、testsuite/ld-empic のコードを参照してください。

--fatal-warnings

すべての警告を、エラーとして扱います。

--force-exe-suffix

出力ファイルのサフィックスが .exe となるようにします。

このオプションを指定すると、無事に生成され完全にリンクされた 出力ファイルに ".exe" や ".dll" という サフィックスがついていなかった場合、リンカは出力ファイルを、同じ名前に ".exe" サフィックスをつけたファイルにコピーします。 このオプションは、Microsoft Windows ホスト上で、 未修正の Unix 用の makefile を使用する場合に便利です。 というのも、Windows のいくつかのバージョンでは、 ".exe" サフィックスがついていないイメージを 実行できないからです。

--no-gc-sections

--gc-sections

未使用の入力セクションのガーベージコレクションを有効にします。 このオプションをサポートしていないターゲット上では無視されます。 このオプションは、-r とは互換性がありませんし、 動的リンクと一緒に使うべきでもありません。 デフォルトの動作 (ガーベージコレクションを実行しない) に戻すには、 コマンドラインで --no-gc-sections を指定してください。

--help

コマンドラインオプションの概要を標準出力に表示し、終了します。

--target-help

ターゲット固有のオプションの要約を標準出力に表示し、終了します。

-Map mapfile

リンクマップをファイル mapfile へ出力します。 前出の -M オプションの記述を参照してください。

--no-keep-memory

通常 ld は、入力ファイルのシンボルテーブルをメモリに キャッシュすることで、メモリ使用量よりも速度を優先します。 このオプションを指定すると、ld は、必要に応じて シンボルテーブルを読むことで、メモリ使用量を最小にします。 これは、大きな実行形式をリンクする際に、ld が メモリ空間を使い果たしてしまうような場合に必要となります。

--no-undefined

-z defs

通常オブジェクトファイルからの未解決シンボルの参照を報告します。 非シンボル共有ライブラリを生成している場合にもこの報告がなされます。 リンクされている共有ライブラリにおける未解決参照の報告動作の 制御は、スイッチ --[no-]allow-shlib-undefined です。

--allow-multiple-definition

-z muldefs

通常、シンボルが複数回定義されると、リンカは致命的なエラーを報告します。 これらのオプションは複数回の定義を許し、最初の定義を使用するようになります。

--allow-shlib-undefined

--no-allow-shlib-undefined

共有ライブラリ中の未定義シンボルを許可 (デフォルト) もしくは 不許可にします。 このスイッチは、未定義シンボルが通常オブジェクトファイルではなく 共有ライブラリに存在する場合の挙動を決定するところを除けば --no-undefined と同様です。 このスイッチは、通常オブジェクトファイルに置ける未定義シンボルの 扱いには影響しません。

デフォルトが --allow-shlib-undefined となっている理由は、 シンボルが実際にはロード時に解決可能となる場合があり、 リンク時に指定されている共有ライブラリが実行時の共有ライブラリと 同じものとは限らないということにあります。 それに加えて、(BeOS のように) 共有ライブラリ中の未定義シンボルが 正常であるシステムの存在があります (カーネルは未定義シンボルを含む 共有ライブラリにロード時にパッチを当て、現在のアーキテクチャで 最適な関数を選択します。 これは例えば適切な memset 関数を 動的に選択するといったことです)。 HPPA の共有ライブラリもまた、未定義シンボルを持つことは 正常なのは明らかです。

--no-undefined-version

通常は、シンボルが未定義バージョンを持つ場合、リンカはこれを無視します。 このオプションは、未定義バージョンのシンボルを許さず、 代りに致命的なエラーを報告します。

--no-warn-mismatch

通常 ld は、不適当な入力ファイルをリンクしようとした場合、 エラーを発します。 例えば、異なるプロセッサ向け、もしくは異なるエンディアン向けに コンパイルされたものであるという場合です。 このオプションを指定すると、ld は、このような起き得るエラーを だまって許可します。 このオプションは、リンカのエラーが適切でないと分かっている 特殊なことした時のみ使用し、使用の際には注意しなくてはなりません。

--no-whole-archive

以後に続くアーカイブファイルに対して、 --whole-archive オプションの効果を無効にします。

--noinhibit-exec

利用可能ならいつも、実行形式の出力ファイルを残しておきます。 普通リンカは、リンク処理中にエラーが発生した場合、 出力ファイルを生成しません。 どんなエラーが発生しても、出力ファイルを書かずに終了します。

-nostdlib

コマンドライン上で明示的に指定されたライブラリディレクトリのみを検索します。 リンカスクリプト中で指定されたライブラリディレクトリは、 (コマンドライン上で指定されたリンカスクリプトであっても) 無視されます。

--oformat output-format

ld は、2 種類以上のオブジェクトファイルをサポートするように 構成することができます。 ld がそのように構成されていた場合、--oformat オプションを 用いて、出力ファイルのバイナリ形式を指定することができます。 しかし ld が別のオブジェクト形式をサポートするよう 構成されていたとしても、通常はこのオプションを指定する必要はありません。 というのも、ld は、それぞれのマシン上で最もありふれた形式を デフォルトの出力形式とするよう構成されているはずだからです。 output-format はテキスト文字列で、BFD ライブラリによって サポートされている特定の形式の名前です (objdump -i を用いて、利用可能なバイナリ形式をリストできます)。 スクリプトコマンド "OUTPUT_FORMAT" でも、出力形式を 指定することができますが、このオプションによって上書きされます。

-pie

--pic-executable

位置独立実行形式を生成します。 現在のところ、これは ELF プラットフォームでのみサポートされています。 位置独立実行形式は、共有ライブラリと同様に、 OS が選択した仮想アドレス (呼び出しごとに異なる) に 動的リンカにより再配置されます。 動的リンクされた通常の実行形式のように、位置独立実行形式は実行可能ですが、 実行形式中で定義されるシンボルは共有ライブラリにより上書きできません。

-qmagic

このオプションは、Linux 互換性のために無視されます。

-Qy

このオプションは、SVR4 互換性のために無視されます。

--relax

マシン依存の効果を持つオプションです。 このオプションをサポートしているターゲットは、少数です。

いくつかのプラットホームでは、--relax オプションは、 リンカがプログラム中のアドレッシングを解決できる場合に可能となる 大域的な最適化を実行します。 これは、出力オブジェクトファイル中のアドレスモードの緩和や、 新規命令の合成などです。

いくつかのプラットホーム上では、このようなリンク時の大域的な最適化によって、 生成された実行形式のシンボリックデバッグが不可能となる場合があります。 不可能になることが知られているのは、松下の MN10200 や MN10300 プロセッサファミリです。

これがサポートされていないプラットホームでは、 --relax は受け付けられますが、無視されます。

--retain-symbols-file filename

ファイル filename 中にリストされたシンボルのみを残し、 他のシンボルをすべて破棄します。 filename は、1 行ごとに 1 つのシンボル名が書いてある 単なる平坦なファイルです。 このオプションは特に、実行時のメモリを節約するために、 1 つの大きい大域的なシンボルテーブルが徐々に増えていく (VxWorks のような) 環境で役にたちます。

--retain-symbols-file は、未定義シンボルや 再配置に必要なシンボルは廃棄しません。

--retain-symbols-file は、 コマンドライン上で 1 回しか指定することができません。 これは、-s や -S を無効にします。

-rpath dir

実行時ライブラリ検索パスへディレクトリを追加します。 これは、ELF 実行形式を共有オブジェクトとリンクする時に 使用されます。 すべての -rpath の引数は結合され、動的リンカに渡されます。 動的リンカは、これらを用いて実行時に共有オブジェクトを検索します。 -rpath オプションは、明示的にリンクされる共有オブジェクトによって 必要とされる共有オブジェクトを検索するのにも使用されます。 これについては、-rpath-link オプションの記述を参照してください。 ELF 実行形式をリンクする時に -rpath が使用されてない場合、 環境変数 "LD_RUN_PATH" の内容が定義されていれば、 それが使われます。

-rpath オプションは、SunOS 上でも使用されます。 SunOS 上ではデフォルトで、リンカは指定されたすべての -L オプションから実行時検索パスを作成します。 -rpath オプションが指定された場合、実行時検索パスは -L オプションを無視し、-rpath オプションのみを用いて作成されます。 このオプションは、gcc を使用する時に役に立ちます。 というのは、gcc は沢山の -L オプションを追加し、それは NFS マウントされたファイルシステム上にあるかもしれないからです。

他の ELF リンカとの互換性のために、-R オプションの後に ファイル名ではなくディレクトリ名が続いた場合、 -rpath オプションとして扱われます。

-rpath-link DIR

ELF もしくは SunOS を使用した場合、ある共有ライブラリが もう 1 つ別の共有ライブラリを要求することがあります。 これは、"ld -shared" としてリンクした時、 入力ファイルの 1 つに共有ライブラリが含まれている場合に起こります。

非共有、再配置不可のリンクを行う時にリンカがそのような依存性に出合うと、 それが明示的にリンクされてない場合、リンカは要求された共有ライブラリを 自動的に探し、リンクに含めようとします。 そのような場合、-rpath-link オプションは、検索する最初の ディレクトリの組を指定します。 -rpath-link オプションで一連のディレクトリ名を指定するには、 コロン区切りの名前のリストで指定してもいいですし、 複数回オプションを指定しても構いません。

このオプションは注意深く使用しなければなりません。 というのも、これはコンパイル時に共有ライブラリに埋め込まれた 検索パスを上書きしてしまうからです。 そのような場合、動的リンカが使用するのとは違った検索パスが、 意図せずに使用されてしまうことがあります。

リンカは、要求された共有ライブラリを探す際に以下の検索パスを使用します。

1.

-rpath-link オプションによって指定されたすべてのディレクトリ。

2.

-rpath オプションで指定されたすべてのディレクトリ。 -rpath と -rpath-link の違いは、-rpath オプションで 指定されたディレクトリは、実行形式に含められ実行時に使用されますが、 -rpath-link オプションは、リンク時にのみ影響します。 これは、ネイティブのリンカ専用です。

3.

ELF システム上で -rpath もしくは "rpath-link" オプションが使われなかった場合、 環境変数 "LD_RUN_PATH" の内容が検索されます。 これは、ネイティブのリンカ専用です。

4.

SunOS 上で -rpath が使われなかった場合、 -L オプションで指定されたすべてのディレクトリが検索されます。

5.

ネイティブのリンカの場合、環境変数 "LD_LIBRARY_PATH" の内容。

6.

ネイティブの ELF リンカの場合、共有ライブラリの "DT_RUNPATH" もしくは "DT_RPATH" 中の ディレクトリが、必要とされる共有ライブラリの検索に使用されます。 "DT_RUNPATH" エントリが存在した場合、 "DT_RPATH" エントリは無視されます。

7.

デフォルトのディレクトリ。 通常、/lib と /usr/lib です。

8.

ELF システム上のネイティブなリンカの場合、 ファイル /etc/ld.so.conf が存在していたら、 そのファイル中のディレクトリのリスト。

要求された共有ライブラリが見つからない場合、 リンカは警告を出しリンクを継続します。

-shared

-Bshareable

共有ライブラリを作成します。 現在これは、ELF, XCOFF, SunOS 上のみでサポートされています。 SunOS 上では、-e オプションが使用されておらず、リンク時に 未定義シンボルが存在していれば、リンカは自動的に共有ライブラリを作成します。

--sort-common

このオプションを指定すると、ld は、コモンシンボルを 適切な出力セクションに配置する際にサイズでソートします。 最初にすべての 1 バイトのシンボルが配置され、次にすべての 2 バイトのシンボル、 そしてすべての 4 バイトのシンボル、そしてその他のシンボルが配置されます。 このようにするのは、アラインメントの制約によってシンボルの間に 隙間が生じるのを防ぐためです。

--split-by-file [size]

--split-by-reloc と同じですが、各々の入力ファイルに対し、 size に達するたびに新しい出力セクションを作成します。 size が指定されなかった場合、デフォルトのサイズは 1 です。

--split-by-reloc [count]

ファイル中の 1 つの出力セクションが、count より多い再配置情報を 含まないよう、出力ファイル中に余分なセクションを作成しようとします。 これは、COFF オブジェクト形式のリアルタイムカーネルに ダウンロードするための巨大な再配置可能ファイルを作成する時に役に立ちます。 というのも、COFF では 1 つのセクションは 65535 を越える 再配置情報を表現することができないからです。 このオプションは、任意のセクションをサポートしていない オブジェクトファイル形式では、うまくいかないことに注意してください。 リンカは、分配し直す際に個々の入力セクションを分割しないので、 1 つの入力セクションが count を越える再配置情報を含んでいる場合、 1 つの出力セクションには、それだけの数の再配置情報を含むことになります。 count のデフォルト値は 32768 です。

--stats

実行時間やメモリ使用量などといったリンカの処理に関する統計情報を、 計算し出力します。

--traditional-format

ターゲットによっては、ld の出力が既存のリンカの出力と いくつかの点で異なることがあります。 このスイッチを指定すると、 ld は既存のリンカの形式を使います。

例えば SunOS 上では、ld はシンボル文字列テーブル内の 重複したエントリを 1 つにします。 これによって、完全なデバッグ情報を持つ出力ファイルのサイズが、 30% 以上も小さくなります。 残念なことに、SunOS の "dbx" プログラムは、 生成されたファイルを読み込むことができません ("gdb" では問題ありません)。 --traditional-format スイッチを指定すると、 重複したエントリを 1 つにまとめません。

--section-start sectionname=org

出力ファイル中のセクションを、org で指定された絶対アドレスに 配置します。 複数のセクションを配置させる場合、このオプションは、 必要に応じてコマンドライン中に何度でも指定することができます。 org は、単独の 16 進数でなければなりません。 他のリンカとの互換性のために、16 進数の先頭に通常つける 0x を 省略することができます。 sectionname と等号 (``='')、org の間には 空白をはさむことができないことに注意してください。

-Tbss org

-Tdata org

-Ttext org

--section-start と同じです。 それぞれ ".bss", ".data", ".text" を sectionname とします。

--unresolved-symbols=method

未解決のシンボルをどのように扱うかを決定します。 method が取り得る値は 4 種類あります。

ignore-all

未解決シンボルを一切報告しません。

report-all

未解決シンボルのすべてを報告します。 これがデフォルトです。

ignore-in-object-files

共有ライブラリが含む未解決シンボルを報告しますが、 通常オブジェクトファイルに由来する場合は無視します。

ignore-in-shared-libs

通常オブジェクトファイルに由来する未解決シンボルを報告しますが、 共有ライブラリに由来する場合は無視します。 動的バイナリを生成する場合に有益な場合があり、その場合、 動的バイナリが参照すべき共有ライブラリすべてをリンカのコマンド行に 含めておく必要があることが知られています。

共有ライブラリそれ自身に対する動作は --[no-]allow-shlib-undefined オプションを 使うことでもまた制御できます。

通常、リンカは、 未解決シンボルの報告それぞれにたいしてエラーメッセージを生成しますが、 オプション --warn-unresolved-symbols により、 エラーを警告に変更することができます。

--dll-verbose

--verbose

ld のバージョン番号と、サポートしているリンカエミュレーションの 一覧を表示します。 また、どの入力ファイルがオープンできて、 どの入力ファイルがオープンできないのかも表示します。 さらに、使用されるリンカスクリプトも表示します。

--version-script=version-scriptfile

リンカに、バージョンスクリプト名を指定します。 これは通常、共有ライブラリを生成する際に使われ、生成するライブラリの バージョン階層についての付加的な情報を指定します。 このオプションは、共有ライブラリをサポートする ELF プラットフォーム上でのみ意味があります。

--warn-common

コモンシンボルが、別の共有シンボルやシンボル定義と結びつけられた時に 警告を出します。 Unix のリンカは、このちょっといい加減な慣習を許していますが、 他のオペレーティングシステム上のリンカは、許していません。 このオプションを指定すると、グローバルシンボルが結びつけられることから来る 潜在的な問題を発見することができます。 残念なことに、C ライブラリの中にはこの慣習を使用しているものがあり、 プログラム中だけでなくライブラリ中のシンボルに対しても、 この警告が出されることがあります。

グローバルシンボルには 3 種類あります。 以下で C 言語の例を使って説明します。

int i = 1;

定義です。 出力ファイル中の初期化済みデータセクションに置かれます。

extern int i;

未定義参照です。 メモリは割り当てられません。 この変数に対する定義かコモンシンボルが、どこかになくてはなりません。

int i;

コモンシンボルです。 変数に対して、(1 つもしくは複数の) コモンシンボルしかない場合、 出力ファイルの非初期化データ領域に置かれます。 リンカは、同じ変数に対する複数のコモンシンボルを、1 つのコモンシンボルへと まとめます。 それらのサイズか異なっていた場合、最も大きなサイズの領域が取られます。 同じ変数に対して定義があった場合、リンカは共有シンボルを宣言に変換します。

--warn-common オプションを指定すると、 リンカは 5 種類の警告を出します。 それぞれの警告は、2 行からなっています。 最初の行は、今出会ったシンボルを説明しており、 次の行は、以前に同じ名前で出会ったシンボルを説明します。 2 つのシンボルの片方、もしくは両方は、コモンシンボルです。

1.

シンボルに対する定義が既に存在するため、 コモンシンボルを参照に変換します。

        <file>(<section>): warning: common of `<symbol>'
           overridden by definition
        <file>(<section>): warning: defined here

2.

シンボルに対する定義が後から現れたため、 コモンシンボルを参照に変換します。 これは上記のケースと同様ですが、シンボルの現れた順番が違います。

        <file>(<section>): warning: definition of `<symbol>'
           overriding common
        <file>(<section>): warning: common is here

3.

コモンシンボルを、既出の同じサイズのコモンシンボルにマージします。

        <file>(<section>): warning: multiple common
           of `<symbol>'
        <file>(<section>): warning: previous common is here

4.

コモンシンボルを、既出の、より大きいコモンシンボルにマージします。

        <file>(<section>): warning: common of `<symbol>'
           overridden by larger common
        <file>(<section>): warning: larger common is here

5.

コモンシンボルを、既出の、より小さいコモンシンボルにマージします。 これは上記のケースと同様ですが、シンボルの現れた順番が違います。

        <file>(<section>): warning: common of `<symbol>'
           overriding smaller common
        <file>(<section>): warning: smaller common is here

--warn-constructors

グローバルコンストラクタが 1 つでも使われていた場合、警告を出します。 これが役に立つファイル形式はわずかです。 COFF や ELF のような形式では、 リンカはグローバルコンストラクタが使用されていることを検知できません。

--warn-multiple-gp

複数のグローバルポインタ値が出力ファイル中で必要とされる場合、 警告を出します。 このオプションは、Alpha などの特定のプロセッサでのみ意味があります。 具体的に言うと、プロセッサの中には特別なセクション中に 大きな値の定数を置くものがあります。 ある特殊なレジスタ (グローバルポインタ) がこのセクションの中央を 指しており、ベースレジスタ相対のアドレッシングモードを使用して、 定数を効率的に読み込むことができます。 ベースレジスタ相対モードのオフセットが、固定で比較的小さい (例えば 16bit) ため、これによって定数領域の最大サイズが 制限されてしまいます。 従って、大きなプログラムでは、すべての定数を参照するために 複数のグローバルポインタ値を使うことがしばしば必要となります。 このオプションを指定すると、このようなケースが起きた時に警告を出します。

--warn-once

それぞれの未定義シンボルに対して、それを参照しているモジュールごとに 警告を出すのではなく、ただ 1 度だけ警告を出します。

--warn-section-align

アラインメントによって出力セクションのアドレスが変更された場合、 警告を出します。 一般的には、アラインメントはインプットセクションにより設定されます。 アドレスが変更されるのは、それが明示的に指定されなかった場合だけです。 すなわち、"SECTIONS" コマンドが、そのセクションの 開始アドレスを指定しなかった場合です。

--warn-unresolved-symbols

リンカが未解決シンボルを報告しようとするとき (オプション --unresolved-symbols を参照)、普通はエラーを生成します。 このオプションは、エラーの代わりに警告を生成します。

--error-unresolved-symbols

これはリンカのデフォルトの動作で、未解決シンボルを報告しようと するときエラーを生成します。

--whole-archive

コマンドライン上で --whole-archive オプションの後に 指定された各アーカイブに対して、そのアーカイブファイルの中の必要な オブジェクトファイルだけを検索するのではなく、アーカイブ中の すべてのオブジェクトをリンクに含めます。 これはアーカイブを共有ライブラリに変換する時に普通使用され、 生成する共有ライブラリ中にすべてのオブジェクトを強制的に取り込みます。 このオプションは、2 回以上使用しても構いません。

このオプションを gcc から使用する際に、2 つ注意することがあります。 1 つめは、gcc はこのオプションを知りません。 ですから、-Wl,-whole-archive と指定しなければなりません。 2 つめは、アーカイブをリストした後 -Wl,-no-whole-archive を 使うことを忘れないようにしてください。 というのは、gcc は自分でアーカイブのリストをリンクに追加することが あるので、これによる影響を受けないようにする必要があるからです。

--wrap symbol

symbol に対して、ラッパ関数を使用します。 すべての symbol への未定義参照は、 "__wrap_symbol" へと解決されます。 すべての "__real_symbol" への 未定義参照は、symbol へと解決されます。

これによって、システム関数に対するラッパを用意できます。 ラッパ関数は、"__wrap_symbol" という 名前にする必要があります。 ラッパ関数がシステム関数を呼びたい時には、 "__real_symbol" を呼び出すようにします。

以下に簡単な例を示します:

        void *
        __wrap_malloc (size_t c)
        {
          printf ("malloc called with %zd\n", c);
          return __real_malloc (c);
        }

--wrap malloc を使用して、このファイルと一緒に他のコードを リンクした場合、すべての "malloc" 呼び出しは、 関数 "__wrap_malloc" を代わりに呼び出します。 "__wrap_malloc" 中の "__real_malloc" が、 本当の "malloc" 関数を呼び出します。

同様にして "__real_malloc" 関数も用意しておくと、 --wrap オプションが指定されなかった場合にもリンクは成功します。 その場合には、"__real_malloc" の定義を "__wrap_malloc" と同じファイルにおいてはいけません。 このようにすると、リンカがそれを "malloc" へと ラップする前に、アセンブラがこの呼び出しを解決してしまうかもしれません。

--enable-new-dtags

--disable-new-dtags

このリンカは、ELF システムの新しい動的タグを生成することができます。 しかし古い ELF システムは、それらを理解できない場合があります。 --enable-new-dtags を指定した場合、 動的タグは必要に応じて作成されます。 --disable-new-dtags を指定した場合は、 新しい動的タグは作成されません。 デフォルトでは、新しい動的タグは作成されません。 これらのオプションは、ELF システム上でのみ利用可能であることに 注意してください。

i386 PE リンカは、-shared オプションをサポートしています。 これを指定すると、通常の実行形式ではなく 動的リンクライブラリ (DLL) を出力します。 このオプションを使用した時には、名前を "*.dll" と する必要があります。 それに加え、リンカは標準の "*.def" ファイルを完全に サポートしており、オブジェクトファイルと同様にリンカのコマンドライン上で 指定できます (実際、シンボルをエクスポートしているアーカイブの前に置いて、通常の オブジェクトファイルと同様にリンクされることを保証する必要があります)。

すべてのターゲットに共通のオプションに加え、i386 PE のリンカは、 i386 PE ターゲットに固有のコマンドラインオプションを 追加でサポートしています。 値を取るオプションは、1 つの空白か等号で値との間を区切ります。

--add-stdcall-alias

このオプションが指定された場合、stdcall サフィックス (@nn) を持つ シンボルを、そのままサフィックスを取ってエクスポートします。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--base-file file

dlltool を使用して DLL を生成するのに必要なすべての再配置情報の ベースアドレスをセーブするファイル名を file とします。 [このオプションは i386 PE 特有です]

--dll

通常の実行形式の代わりに DLL を生成します。 -shared を使用することもできますし、指定した ".def" ファイル中で "LIBRARY" を 使用することもできます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--enable-stdcall-fixup

--disable-stdcall-fixup

解決不能なシンボルを見つけると、リンカは「曖昧リンク」を試みます。 これは、シンボル名の形式 (cdecl 対 stdcall) だけが異なる別の定義済みの シンボルを探し、一致したものへとリンクすることでシンボルを解決します。 例えば、未定義シンボル "_foo" は、関数 "_foo@12" へとリンクされ、未定義シンボル "_bar@16" は、関数 "_bar" へと リンクされるかも知れません。 リンカがこれを行う際に、警告を表示します。 というのは、通常はリンクに失敗するべきであるからです。 しかし、サードパーティの DLL から生成されたインポートライブラリを 使用するのに、この機能が時々必要となることがあります。 --enable-stdcall-fixup を指定した場合、この機能は 完全に有効化され、警告は出力されません。 --disable-stdcall-fixup を指定した場合、この機能は 無効化され、そのような不一致はエラーとみなされます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--export-all-symbols

このオプションが指定されると、DLL を構築するのに使われる オブジェクト中のすべてのグローバルシンボルが、DLL によって エクスポートされます。 これは、こうしなければエクスポートされるシンボルが全くない場合、 デフォルトとなることに注意してください。 シンボルが DEF ファイルによって明示的にエクスポートされる場合や 関数属性によって暗黙にエクスポートされる場合は、このオプションが 指定されない限り、デフォルトでは他には何もエクスポートされません。 シンボル "DllMain@12", "DllEntryPoint@0", "DllMainCRTStartup@12", "impure_ptr" は、 自動的にはエクスポートされません。 他の DLL からインポートされたシンボルも、再びエクスポートされませんし、 "_head_" で始まったり "_iname" で 終るような、DLL の内部レイアウトを指定するシンボルもエクスポートされません。 さらに、"libgcc", "libstd++", "libmingw32", "crtX.o" からの シンボルもエクスポートされません。 "__rtti_" や "__builtin_" で 始まる名前のシンボルも、C++ DLL のためにエクスポートされません。 最後に、エクスポートされない Cygwin の非公開シンボルの 拡張されたリストもあります (明らかに、これは Cygwin ターゲット用の DLL を構築する時に適用されます)。 これら Cygwin の除外されるシンボルは以下の通りです。 "_cygwin_dll_entry@12", "_cygwin_crt0_common@8", "_cygwin_noncygwin_dll_entry@12", "_fmode", "_impure_ptr", "cygwin_attach_dll", "cygwin_premain0", "cygwin_premain1", "cygwin_premain2", "cygwin_premain3" そして "environ" です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--exclude-symbols symbol,symbol,...

自動的にエクスポートすべきではないシンボルのリストを指定します。 それらのシンボル名は、コンマもしくはコロンで区切られます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--exclude-libs lib,lib,...

シンボルを自動的にエクスポートしないアーカイブライブラリのリストを指定します。 ライブラリ名はコンマかコロンで区切ります。 "--exclude-libs ALL" と指定すると、 自動エクスポートのすべてのアーカイブライブラリからシンボルを除去します。 明示的に .def ファイルにリストされたシンボルは、本オプションにかかわらず、 依然としてエクスポートされます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--file-alignment

ファイルのアラインメントを指定します。 ファイル中のセクションは、常にこの倍数のファイルオフセットから 始まります。 デフォルトは 512 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--heap reserve

--heap reserve,commit

このプログラムのヒープ領域に使うために予約する (オプションでコミットする) メモリ量を指定します。 デフォルトでは 1Mb が予約され、4K がコミットされます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--image-base value

プログラムもしくは DLL のベースアドレスとして、value を使用します。 これは、プログラムもしくは DLL がロードされた時に使われる、 最も低位のメモリ位置となります。 再配置する必要性を軽減し、DLL の性能を向上させるため、各 DLL は 一意なベースアドレスを持ち、他の DLL と重ならないようにすべきです。 デフォルトでは、実行形式は 0x400000 で、DLL は 0x10000000 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--kill-at

このオプションが指定されると、stdcall のサフィックス (@nn) は、 エクスポートされる前にシンボルから取り除かれます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--major-image-version value

「イメージバージョン」のメジャーナンバを設定します。 デフォルトは 1 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--major-os-version value

「OS バージョン」のメジャーナンバを設定します。 デフォルトは 4 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--major-subsystem-version value

「サブシステムバージョン」のメジャーナンバを設定します。 デフォルトは 4 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--minor-image-version value

「イメージバージョン」のマイナナンバを設定します。 デフォルトは 0 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--minor-os-version value

「OS バージョン」のマイナナンバを設定します。 デフォルトは 0 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--minor-subsystem-version value

「サブシステムバージョン」のマイナナンバを設定します。 デフォルトは 0 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--output-def file

リンカは、生成する DLL に対応した DEF ファイルを含む ファイル file を作成します。 この DEF ファイル ("*.def" と呼ばれます) は、 "dlltool" を使ってインポートライブラリの作成に 使用されたり、自動的にもしくは暗黙にエクスポートされるシンボルへの 参照として使用されたりします。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--out-implib file

リンカは、生成する DLL に対応したインポートライブラリを含む ファイル file を作成します。 このインポートライブラリ ("*.dll.a" もしくは "*.a" と呼ばれます) は、 生成された DLL をクライアントにリンクするのに使われます。 この動作によって、別に行う "dlltool" の インポートライブラリ作成ステップを飛ばすことができます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--enable-auto-image-base

"--image-base" 引数によって指定されなかった DLL の イメージベースを自動的に選択します。 DLL 名から生成されるハッシュ値を使うことにより、各 DLL に対して 一意のイメージベースが作成され、プログラムの実行を遅延させる メモリ内での衝突と再配置を回避することができます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--disable-auto-image-base

一意なイメージベースを自動的に作成しません。 ユーザから指定されたイメージベース ("--image-base") が ない場合、プラットフォームのデフォルトを使用します。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--dll-search-prefix string

インポートライブラリを使わずに DLL を動的にリンクする際に、 "lib<basename>.dll" よりも "<string><basename>.dll" を先に検索します。 この動作によって、様々な ``subplatforms'' 用に作られた native, cygwin, uwin, pw などの DLL を、容易に区別することができます。 例えば、一般的に Cygwin の DLL は、 "--dll-search-prefix=cyg" を使用します。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--enable-auto-import

DLL からインポートするデータに対して、"_symbol" を "__imp__symbol" へと手の込んだリンクをし、 それらの DATA エクスポートを持つインポートライブラリの 構築に際して、 必要に応じてサンク (thunk) したシンボルを作成します。 注意: 'auto-import' 拡張機能の使用はイメージファイルの テキストセクションを書き込み可能にしてしまいます。 これは Microsoft が発行している PE-COFF 形式仕様に適合しません。

一般的に、'auto-import' の使用は、単にうまくいきます。 --- しかし、以下のようなメッセージが出ることがあります。

"variable '<var>' can't be auto-imported. Please read the documentation for ld's "--enable-auto-import" for details."

このメッセージは、最終的に 2 つの定数の和によって指定されるアドレスに アクセスする(サブ)式がある場合に発生します (Win32 インポートテーブルは、1 つのみしか許していません)。 これが起こり得る場合というのは、DLL からインポートされた構造体変数の フィールドメンバへアクセスする場合や、 DLL からインポートされた 配列変数に対して定数のインデックスを使用する場合などがあります。 すべての複数ワードの変数 (配列、構造体、long long など) は、 このエラー条件を引き起こすことがあります。 しかし、このエクスポートされた目障りな変数が、実際どんなデータタイプで あっても、ld は 常にこれを検知し、警告を発し、停止します。

エクスポートされた変数のデータタイプが何であろうと、 この問題を解消する方法がいくつかあります。

1 つの方法は、--enable-runtime-pseudo-reloc スイッチを 使用することです。 これは実行環境のクライアントコードに参照の調整という仕事を 残してしまうことになるので、この方法が使えるのは、 実行環境がこの機能をサポートしている場合に限られます。

2 番目の解決策は、定数の 1 つを強制的に変数としてしまうことです。 --- つまり、コンパイル時に不明で最適化不可とすることです。 配列に対しては、2 つの方法が考えられます。 a) インデックスされる側 (配列のアドレス) を変数とします。 もしくは、b) 定数インデックスを変数とします。 従って以下のようになります:

        extern type extern_array[];
        extern_array[1] --> 
           { volatile type *t=extern_array; t[1] }

もしくは

        extern type extern_array[];
        extern_array[1] --> 
           { volatile int t=1; extern_array[t] }

構造体 (や、他のほとんどの複数ワードデータタイプ) に対しては、 構造体そのもの (もしくは long long など) を変数とするのが、 唯一の方法です。

        extern struct s extern_struct;
        extern_struct.field --> 
           { volatile struct s *t=&extern_struct; t->field }

もしくは

        extern long long extern_ll;
        extern_ll -->
          { volatile long long * local_ll=&extern_ll; *local_ll }

この問題を扱う 3 番目の方法は、目障りなシンボルを「自動インポート」するのを 止めて、"__declspec(dllimport)" と印を付けることです。 しかし実際にこれをするには、コンパイル時に #define を使い、 DLL を構築しようとしているのか、もしくは DLL とリンクする クライアントコードを構築しようとしているのか、または単に静的ライブラリを 構築/リンクしようとしているのかを示さなければなりません。 「定数オフセットを用いた直接アドレス」問題を解決するいくつかの方法を 選択する際に、一般的な現実世界での使用方法を考えなければなりません:

元のコード:

        --foo.h
        extern int arr[];
        --foo.c
        #include "foo.h"
        void main(int argc, char **argv){
          printf("%d\n",arr[1]);
        }

解決策 1:

        --foo.h
        extern int arr[];
        --foo.c
        #include "foo.h"
        void main(int argc, char **argv){
          /* This workaround is for win32 and cygwin; do not "optimize" */
          volatile int *parr = arr;
          printf("%d\n",parr[1]);
        }

解決策 2:

        --foo.h
        /* Note: auto-export is assumed (no __declspec(dllexport)) */
        #if (defined(_WIN32) || defined(__CYGWIN__)) && \
          !(defined(FOO_BUILD_DLL) || defined(FOO_STATIC))
        #define FOO_IMPORT __declspec(dllimport)
        #else
        #define FOO_IMPORT
        #endif
        extern FOO_IMPORT int arr[];
        --foo.c
        #include "foo.h"
        void main(int argc, char **argv){
          printf("%d\n",arr[1]);
        }

この問題を回避する 4 番目の方法は、目障りな変数に対するアクセスを、 データを直接使うインタフェースではなく、関数のインタフェースを使うよう ライブラリを書き換えることです (例えば set_foo() と get_foo() アクセス関数を使います)。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--disable-auto-import

DLL からインポートしたデータに対して、"_symbol" を "__imp__symbol" へと、手の込んだリンクを しないようにします。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--enable-runtime-pseudo-reloc

コードが --enable-auto-import セクションで記述した表現を含む場合、 すなわち、 DATA が DLL から非ゼロオフセットを付けて インポートしている場合、このスイッチは '実行時疑似再配置 (runtime pseudo relocation)' ベクタを生成します。 このベクタは実行環境がクライアントコードの中でそれらデータの参照を 調整するために使用することができます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--disable-runtime-pseudo-reloc

DLL からの、非ゼロオフセットの DATA インポートに対する 疑似再配置情報を生成しないようにします。 これはデフォルトです。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--enable-extra-pe-debug

自動インポートしたシンボルのサンクに関して、付加的なデバッグ情報を示します。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--section-alignment

セクションのアラインメントを設定します。 メモリ中のセクションは、常にこの倍数のアドレスから始まります。 デフォルトは 0x1000 です。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--stack reserve

--stack reserve,commit

プログラムのスタックに使うために予約する (オプションでコミットする) メモリ量を指定します。 デフォルトでは 2Mb が予約され、4K がコミットされます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

--subsystem which

--subsystem which:major

--subsystem which:major.minor

プログラムが実行されるサブシステムを指定します。 which の値で有効なのは、"native", "windows", "console" そして "posix" です。 オプションで、サブシステムのバージョンも指定することもできます。 [このオプションは i386 PE ターゲット用移植版リンカに 特有のものです]

索引

環境変数

"GNUTARGET" は、-b (もしくはその別名の --format) が指定されなかった場合、 入力ファイルのオブジェクト形式を決定するのに使用されます。 その値は、入力形式に対する BFD 名の 1 つでなくてはなりません。 環境変数 "GNUTARGET" が定義されていない場合、 ld は、そのターゲットに最も自然な形式を使用します。 "GNUTARGET" が "default" に 設定されていた場合、BFD は、バイナリ入力ファイルを検査して インプット形式を決定しようとします。 この方法は大抵の場合成功しますが、潜在的な曖昧さが残ります。 というのは、オブジェクトファイルの形式を指定するのに使われる マジックナンバが一意であることを保証する方法がないからです。 しかし、それぞれのシステム上での BFD の構成過程において、 そのシステムの慣習的なフォーマットが検索リストの先頭に置かれるので、 この曖昧さは慣習的なものに有利になるように解決されます。

"LDEMULATION" は、-m オプションが 指定されなかった場合、デフォルトのエミュレーションを決定するのに 使用されます。 エミュレーションは、リンカの動作の様々な面、特にデフォルトの リンカスクリプトに影響を与えます。 利用可能なエミュレーションの一覧は、--verbose もしくは -V オプションを指定することで表示できます。 -m オプションが使用されず、"LDEMULATION" 環境変数も 定義されていなかった場合、デフォルトのエミュレーションは、リンカが どのように構成されたかに依存します。

通常、リンカはデフォルトでシンボルをデマングルします。 しかし、"COLLECT_NO_DEMANGLE" 環境変数が設定された場合は、 デフォルトでシンボルをデマングルしません。 この環境変数は、gcc のリンカラッパプログラムでも同様に使用されています。 デフォルトは、--demangle と --no-demangle オプションで 上書きすることができます。  

索引

関連項目

索引

COPYRIGHT

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.  

索引

謝辞

索引

Index

名称

書式

解説

オプション

環境変数

関連項目

COPYRIGHT

謝辞