名称

ld - GNU リンカ

書式

ld [ options] objfile ...

解説

ld は、いくつかのオブジェクトファイルとアーカイブファイルを結合し、そのデータを再配置し、シンボルの参照を結びつけます。通常、プログラムのコンパイルの最終段階が、 ld を実行することです。

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

このマニュアルページは、コマンド言語を説明していません。コマンド言語と GNU リンカの他の局面での完全な詳細については、 "info"の ld エントリを参照してください。

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

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

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

オプション

このリンカは、おびただしい量のコマンドラインオプションを備えていますが、実際には、いかなる局面においても使用されるオプションは、少ししかありません。例えば、 ld がよく使われるのは、Unix の標準のオブジェクトファイルを、サポートする標準の Unix システム上でリンクする場合です。そのようなシステム上では、"hello.o"というファイルをリンクするためには以下のようにします:

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

これは、"/lib/crt0.o"と "hello.o"、そして標準で検索されるディレクトリにあるライブラリ "libc.a"をリンクして、 output という名前のファイルを生成することを ld に対して指示しています。 (下記の -l オプションの議論を参照してください。)

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 リンカが受け入れる一般的なコマンドラインスイッチの一覧です:

@ file

file からコマンドラインのオプションを読み込みます。読み込まれたオプションは、オリジナルの @ file オプションの場所に代わって挿入されます。 file が存在しないか、または読み込むことができないなら、オプションは、文字通りに扱われ、取り除かれません。

 

file 中のオプションは、空白類によって分離されます。空白類の文字は、シングルクォートまたはダブルクォートのいずれかで全体のオプションを囲むことによって、オプションに含めることができます。 (バックスラッシュを含む) 任意の文字は、バックスラッシュを文字を前に置くことによって、含めることができます。 file は、それ自体に、追加の @ file オプションを含むことができます。そのようなオプションは、再帰的に処理されます。

-a keyword

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

-A architecture

--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 を基数とすることを表します)。

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

シンボルが自動的にエクスポートされるべきでないアーカイブライブラリのリストを指定します。ライブラリ名は、コンマまたはコロンによって区切られます。自動的にエクスポートされたすべてのアーカイブライブラリのシンボルを除いて、 "--exclude-libs ALL"を指定します。このオプションは、リンカの i386 PE をターゲットとするポートと ELF をターゲットとするポートのためだけに利用可能です。 i386 PE に関して、このオプションにかかわらず、 .def ファイルに明白にリストされたシンボルは、それでもエクスポートされます。 ELF をターゲットとするポートに関して、このオプションによって影響するシンボルは、隠されるように扱われます。

-E

--export-dynamic

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

 

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

 

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

 

出力形式が動的なリストをサポートするなら、どのようなシンボルが動的なシンボルテーブルに加えられるべきであるかを制御するために動的なリストを使用することもできます。 --dynamic-list の説明を参照してください。

-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

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

-G value

--gpsize= value

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

-h name

-soname= name

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

-i

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

-init name

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

-l namespec

--library= namespec

リンクするためのファイルのリストに namespec によって指定されたアーカイブまたはオブジェクトファイルを追加します。このオプションは、いくつでも使用することができます。 namespec が : filename の形式であるなら、 ld は、 filename と呼ばれるファイルのためのライブラリパスを検索し、そうでなければ、 lib namespec .a と呼ばれるファイルのためのライブラリパスを検索します。

 

共有ライブラリをサポートするシステムでは、 ld は、 lib namespec .a 以外のファイルも検索するかもしれません。具体的に、ELF と SunOS システムでは、 ld は、 lib namespec .a と呼ばれるファイルを検索する前に、 lib namespec .so と呼ばれるライブラリのためのディレクトリを検索します。 (慣例により、".so"拡張子は、共有ライブラリを示します。) この振る舞いは、常に filename と呼ばれるファイルを指定する、 : filename に適用されないことに注意してください。

 

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

 

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

 

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

 

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

-L searchdir

--library-path= searchdir

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

 

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

 

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

 

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

-m emulation

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 プラットフォームでしかサポートされていません。

--force-dynamic

強制的に出力ファイルに動的なセクションを持たせます。このオプションは、VxWorks ターゲットに特有です。

-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 オプションは、一つにまとめられます。

-dT scriptfile

--default-script= scriptfile

デフォルトのリンカスクリプトとして scriptfile を使用します。

 

このオプションは、コマンドラインの残りが処理される後まで、スクリプトの処理が遅延されることを除いて、 --script オプションと同様です。これによって、コマンドラインで --default-script オプションの後に置かれたオプションは、ユーザによってリンカコマンドラインを直接制御できないとき、重要となるかもしれない、リンカスクリプトの振る舞いに影響するかもしれません。 (例えば、コマンドラインが gcc のような、別のツールによって設定されるためです)。

-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

すべての一時的なローカルシンボルを削除します。 (これらのシンボルは、システム特有のローカルのラベル接頭辞、通常、ELF システムのためには .L、または伝統的な a.out システムのためのには L で始まります。)

-y symbol

--trace-symbol= symbol

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

 

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

-Y path

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

-z keyword

認識されるキーワードは、次の通りです:

-( 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 オプションが追加されました。

--add-needed

--no-add-needed

このオプションは、 --add-needed オプションの後に、コマンド行で記述された動的なライブラリの ELF DT_NEEDED タグからの動的なライブラリの処理に影響します。通常は、リンカは、生成された出力オブジェクトに各動的ライブラリから DT_NEEDED タグをコピーしません。 --add-needed によって、このフラグの後に記述された、すべての動的なライブラリから DT_NEEDED タグをコピーします。 --no-add-needed は、デフォルトの振る舞いを復元します。

--as-needed

--no-as-needed

このオプションは、 --add-needed が、実質的であるとき、 --as-needed オプションの後に、コマンド行に記述された動的ライブラリのための ELF 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 が暗黙に指定されます。訳注: 原文は --unresolved-symbols=report-all となっている、どちらが正しいか不明。このオプションは、共有ライブラリをサポートする ELF プラットフォーム上でのみ意味を持ちます。

-Bstatic

-dn

-non_shared

-static

共有ライブラリをリンクしません。これは、共有ライブラリをサポートするプラットフォーム上でのみ意味を持ちます。このオプションに異なる形式があるのは、様々なシステムとの互換性のためです。このオプションは、コマンドライン上で何度でも使用することができます。これは、後に続く -l オプションのライブラリ検索に影響します。このオプションは、 --unresolved-symbols=report-all の意味も含みます。 -shared で、このオプションを使用することができます。そうすることは、共有ライブラリが作成されていますが、静的なライブラリからエントリを引くことによってライブラリの外部参照のすべては、解決されなければならないことを意味します。

-Bsymbolic

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

-Bsymbolic-functions

共有ライブラリを作成するとき、もしあれば、グローバル関数のシンボルへの参照を共有ライブラリ内の定義にバインドします。このオプションは、共有ライブラリをサポートする ELF プラットフォームでのみ意味があります。

--dynamic-list= dynamic-list-file

動的なリストファイルの名前をリンカに指定します。参照が共有ライブラリ内で定義するためにバインドされるべきでないグローバルシンボルのリストを指定するために共有ライブラリを作成するか、または実行可能のシンボルテーブルに追加されるべきであるシンボルのリストを指定するために動的にリンクされた実行形式を作成するとき、これは、通常使用されます。このオプションは、共有ライブラリをサポートする ELF プラットフォームでのみ意味があります。

 

動的なリストの形式は、スコープ (範囲) とノード名なしでバージョンノードと同じです。詳しい情報については、 VERSION を参照してください。

--dynamic-list-data

すべてのグローバルなデータシンボルを動的なリストに含めます。

--dynamic-list-cpp-new

C++ 演算子の new と delete のための組み込みの動的なリストを提供します。それは、主に共有された libstdc++ の構築の役に立ちます。

--dynamic-list-cpp-typeinfo

C++ 実行時の識別の組み込みの動的なリストを提供します。

--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 実行形式を生成する時のみ意味があります。通常は、デフォルトの動的リンカで正しいはずです。自分が何をしようとしているのかがわかってる場合以外は、使用しないでください。

--fatal-warnings

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

--force-exe-suffix

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

 

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

--gc-sections

--no-gc-sections

未使用の入力セクションのガーベージコレクションを有効にします。このオプションをサポートしていないターゲット上では無視されます。このオプションは、 -r または --emit-relocs と互換性がありません。コマンドラインで --no-gc-sections を指定することによって、 (このガーベージコレクションを実行しない) デフォルトの振る舞いを復元することができます。

--print-gc-sections

--no-print-gc-sections

ガーベージコレクションによって削除されたすべてのセクションをリストします。リストは、stderr に印刷されます。このオプションは、ガーベージコレクションが --gc-sections オプションによって有効にされる場合に限り有効です。コマンドラインで --no-print-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

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

--default-symver

バージョン化されていない (unversioned) エクスポートされたシンボルのためのデフォルトのシンボルバージョン (soname) を作成して、使用します。

--default-imported-symver

バージョン化されていない (unversioned) インポートされたシンボルのためのデフォルトのシンボルバージョン (soname) を作成して、使用します。

--no-warn-mismatch

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

--no-warn-search-mismatch

通常、 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 オプションで一連のディレクトリ名を指定するには、コロン区切りの名前のリストで指定してもいいですし、複数回オプションを指定しても構いません。

 

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

 

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

-shared

-Bshareable

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

--sort-common

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

--sort-section name

このオプションは、リンカスクリプトのすべてのワイルドカードのセクションパターンに "SORT_BY_NAME"を適用します。

--sort-section alignment

このオプションは、リンカスクリプトのすべてのワイルドカードのセクションパターンに "SORT_BY_ALIGNMENT"を適用します。

--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

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

--sysroot= directory

設定時間のデフォルトを無効にして、sysroot の位置として directory を使用します。このオプションは、 --with-sysroot を使用して設定されたリンカによってのみサポートされます。

--traditional-format

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

 

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

--dll-verbose

--verbose

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

--version-script= version-scriptfile

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

--warn-common

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

 

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

--warn-constructors

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

--warn-multiple-gp

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

--warn-once

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

--warn-section-align

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

--warn-shared-textrel

リンカが DT_TEXTREL を共用オブジェクトに追加するなら、警告します。

--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 %zu\n", c);
return __real_malloc (c);
}

 

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

 

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

--eh-frame-hdr

".eh_frame_hdr"セクションと ELF "PT_GNU_EH_FRAME"セグメントヘッダの作成を要求します。

--enable-new-dtags

--disable-new-dtags

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

--hash-size= number

リンカのハッシュテーブルのデフォルトサイズを number に近い素数に設定します。この値を増加することは、リンカの必要メモリを増加することを犠牲にして、タスクを実行するためにリンカに要する時間の長さを減少させることができます。この値を同様に減少させると、速度を犠牲にして、必要メモリを減少させることができます。

--hash-style= style

リンカのハッシュテーブルのタイプを設定します。 style は、古典的な ELF ".hash"セクションのための "sysv"、新しいスタイルの GNU ".gnu.hash"セクションのための "gnu"、または古典的な ELF ".hash"と新しいスタイルの GNU ".gnu.hash"ハッシュテーブルのための "both"のいずれかを指定することができます。デフォルトは、"sysv"です。

--reduce-memory-overheads

このオプションは、シンクする速度を犠牲にして ld ランタイムに必要なメモリを減少します。これは、シンボルの記憶域のために約 40% より多くのメモリを使用する新しい O(n) アルゴリズムではなく、リンクマップファイル生成のために古い O(n^2) アルゴリズムを選択するために導入されました。

 

スイッチの別の効果は、リンカの実行時間が長くなるコストでメモリを再び節約する、デフォルトのハッシュテーブルのサイズを 1021 に設定することです。しかしながら、 --hash-size スイッチが使用されらたなら、これは、行われません。

 

リンカの将来のバージョンの他のトレードオフを有効にするために --reduce-memory-overheads スイッチも使用されるかもしれません。

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 ターゲットとする移植版のリンカに特有です]

--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 ターゲットとする移植版のリンカに特有です]

--large-address-aware

与えられるなら、COFF ヘッダの "Characteristics"フィールドの適切なビットは、この実行形式が 2 ギガバイトより大きい仮想アドレスをサポートすることを示すように設定されます。これは、BOOT.INI の "[operating systems]"セクションで /3GB または /USERVA= value メガバイトのスイッチと連動して使用されるべきです。そうでなければ、このビットには、効果がありません。 [このオプションは、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 からインポートする DATA に対して、"_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 からインポートした DATA に対して、"_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", と "xbox"です。オプションでサブシステムのバージョンも設定できます。数値も which のために受け付けられます。 [このオプションは、i386 PE ターゲットとする移植版のリンカに特有です]

68HC11 と 68HC12 リンカは、メモリバンク切り換えマッピングとトランポリンコード生成を制御するために特有のオプションをサポートします。

--no-trampoline

このオプションは、トランポリンの生成を無効にします。デフォルトで、トランポリンは、"jsr"命令を使用して呼び出される各 far 関数のために生成されます (far 関数へのポインタが取られるとき、これは、起こります)。

--bank-window name

このオプションは、メモリバンクのウィンドウを記述する MEMORY 仕様でメモリ領域の名前をリンカに示します。次に、そのような領域の定義は、メモリウィンドウ内でページングとアドレスを計算するためにリンカによって使用されます。

環境変数

環境変数 "GNUTARGET", "LDEMULATION", "COLLECT_NO_DEMANGLE"を用いて、 ld の動作を変更することができます。

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

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

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

関連項目

ar(1), nm(1), objcopy(1), objdump(1), readelf(1) そして Info の binutils と ld 項。

COPYRIGHT

Copyright (c) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.

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".

謝辞

この日本語訳の作成にあたり、SRA の矢吹氏 (yabuki@sra.co.jp) の訳を参考にさせていただきました。