コマンドラインのマニュアル

Man » ld マニュアルオンライン - ld man ページの詳細なオンラインドキュメント

🌍
ld - GNUリンカー

概要

ld [オプション] オブジェクトファイル ...

説明

ld は、複数のオブジェクトファイルとアーカイブファイルを結合し、それらのデータを再配置し、シンボルの参照を解決します。通常、プログラムのコンパイルの最後のステップは、ld を実行することです。

ld は、AT&T のリンクエディターコマンド言語のスーパーセットで記述されたリンカコマンド言語ファイルを受け入れ、リンクプロセスを明示的かつ完全に制御できるようにします。

この man ページは、コマンド言語について説明していません。コマンド言語や GNU リンカーの他の側面については、「info」の ld エントリを参照してください。

このバージョンの ld は、汎用 BFD ライブラリを使用してオブジェクトファイル上で動作します。これにより、ld は COFF や「a.out」など、さまざまな形式のオブジェクトファイルを読み込み、結合し、書き込むことができます。異なる形式をリンクして、利用可能なあらゆる種類のオブジェクトファイルを生成できます。

その柔軟性に加えて、GNU リンカーは、診断情報を提供する点で他のリンカーよりも優れています。多くのリンカーは、エラーが発生するとすぐに実行を停止しますが、ld は可能な限り実行を継続し、他のエラーを特定したり、場合によってはエラーが発生しても出力ファイルを取得したりすることができます。

GNU リンカー ld は、幅広い状況に対応し、他のリンカーとの互換性を可能な限り高くするように設計されています。その結果、その動作を制御するための多くの選択肢があります。

オプション

リンカーは多数のコマンドラインオプションをサポートしていますが、実際には、特定の状況でそれらのうちのほんの一部しか使用されていません。たとえば、ld の一般的な使用方法の 1 つは、標準のサポートされている Unix システムで標準の Unix オブジェクトファイルをリンクすることです。そのようなシステムでは、「hello.o」ファイルをリンクするには、次のようにします。

ld -o <出力> /lib/crt0.o hello.o -lc

これは、ld に対して、「/lib/crt0.o」ファイルと「hello.o」ファイル、および標準の検索ディレクトリから取得される「libc.a」ライブラリをリンクして、「出力」という名前のファイルを作成するように指示します。(以下に -l オプションの説明を示します。)

コマンドラインオプションの一部は、コマンドラインの任意の場所に指定できます。ただし、-l や -T などのファイルを参照するオプションは、オブジェクトファイルや他のファイルオプションに関連して、コマンドラインにオプションが現れる時点でファイルを読み込みます。意味のある方法で複数回指定できるオプションは、以下に説明します。

オプション以外の引数は、一緒にリンクされるオブジェクトファイルまたはアーカイブです。これらは、コマンドラインオプションとオプションの引数の間に配置されない限り、コマンドラインオプションの前、後、または間に配置できます。

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

リンカーがオブジェクトファイルの形式を認識できない場合、それはリンカースクリプトであると想定します。このように指定されたスクリプトは、リンクに使用されるメインのリンカースクリプト(デフォルトのリンカースクリプトまたは-Tオプションを使用して指定されたもの)を拡張します。この機能により、リンカーは、オブジェクトまたはアーカイブに見えるファイルに対してリンクできますが、実際には単にいくつかのシンボルの値を定義したり、「INPUT」または「GROUP」を使用して他のオブジェクトをロードしたりします。このようにスクリプトを指定すると、メインのリンカースクリプトが拡張され、追加のコマンドがメインスクリプトの後に配置されます。デフォルトのリンカースクリプトを完全に置き換えるには、-Tオプションを使用しますが、「INSERT」コマンドの効果に注意してください。

名前が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,--start-group foo.o bar.o -Wl,--end-group

これは重要です。そうしないと、コンパイラドライバプログラムがリンカーオプションをサイレントに破棄し、リンクに失敗する可能性があります。値が必要なオプションをドライバに渡すときに混乱が生じる可能性もあります。オプションと引数の間にスペースがあると、区切り文字として機能し、ドライバはオプションのみをリンカーに渡し、引数をコンパイラに渡すことになります。この場合、最も簡単な方法は、1文字と複数の文字の両方のオプションの連結された形式を使用することです。


gcc foo.o bar.o -Wl,-eENTRY -Wl,-Map=a.map

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

@file

コマンドラインオプションをファイルから読み込みます。読み込まれたオプションは、元の@fileオプションの場所に挿入されます。ファイルが存在しないか、読み込めない場合、オプションは文字通りに扱われ、削除されません。

ファイル内のオプションは、空白で区切られます。空白文字をオプションに含めるには、オプション全体を単一引用符または二重引用符で囲みます。バックスラッシュを含むすべての文字は、含めたい文字の前にバックスラッシュを付けて含めることができます。ファイル自体に他の@fileオプションを含めることができます。そのようなオプションは再帰的に処理されます。

-a キーワード

これは、HP/UXとの互換性のためにサポートされています。キーワード引数は、archive、shared、またはdefaultのいずれかの文字列である必要があります。-aarchiveは-Bstaticと同等であり、他の2つのキーワードは-Bdynamicと同等です。このオプションは、任意の回数使用できます。

--audit AUDITLIB

AUDITLIBを、ダイナミックセクションの「DT_AUDIT」エントリに追加します。AUDITLIBは存在するかどうかチェックされず、ライブラリで指定されたDT_SONAMEも使用されません。複数回指定された場合、「DT_AUDIT」にはコロンで区切られた監査インターフェイスのリストが含まれます。リンカーが共有ライブラリを検索中に監査エントリを持つオブジェクトを見つけた場合、出力ファイルにそれに対応する「DT_DEPAUDIT」エントリが追加されます。このオプションは、rtld-auditインターフェイスをサポートするELFプラットフォームでのみ意味があります。

-b 入力形式
--format=入力形式

ldは、複数の種類のオブジェクトファイルをサポートするように構成できます。ldがこのように構成されている場合、-bオプションを使用して、コマンドラインの後の入力オブジェクトファイルのバイナリ形式を指定できます。ldが代替のオブジェクト形式をサポートするように構成されている場合でも、通常はこれを指定する必要はありません。なぜなら、ldは各マシンで最も一般的な形式を入力形式として期待するように構成されているはずだからです。入力形式は、BFDライブラリによってサポートされている特定の形式の名前を持つテキスト文字列です。(利用可能なバイナリ形式は、objdump -iでリストできます。)

ファイルに珍しいバイナリ形式がある場合は、このオプションを使用できます。また、-bを使用して、オブジェクトファイルの形式を明示的に切り替えることもできます(異なる形式のオブジェクトファイルをリンクする場合)。-b入力形式を、特定の形式のオブジェクトファイルのグループの前に含めることで、これを実行できます。

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

スクリプトから入力形式を定義することもできます。これには、「TARGET」コマンドを使用します。

-c MRIコマンドファイル
--mri-script=MRIコマンドファイル

MRIによって生成されたリンカーとの互換性のために、ldは、GNU ldドキュメントのMRI互換スクリプトファイルのセクションで説明されている、代替の制限されたコマンド言語で記述されたスクリプトファイルを受け入れます。MRIスクリプトファイルは、-cオプションで導入します。一般的なldスクリプト言語で記述されたリンカースクリプトを実行するには、-Tオプションを使用します。MRI-cmdfileが存在しない場合、ldは、-Lオプションで指定されたディレクトリでそれを見つけます。


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

--depaudit AUDITLIB
-P AUDITLIB
AUDITLIBを動的セクションの "DT_DEPAUDIT" エントリに追加します。 AUDITLIBの存在はチェックされず、ライブラリで指定されたDT_SONAMEも使用されません。 複数回指定された場合、"DT_DEPAUDIT" には、コロンで区切られた使用する監査インターフェイスのリストが含まれます。 このオプションは、rtld-auditインターフェイスをサポートするELFプラットフォームでのみ意味を持ちます。 -Pオプションは、Solarisとの互換性のために提供されます。

--enable-linker-version
"LINKER_VERSION" リンカースクリプトディレクティブを有効にします。これは、出力セクションデータで説明されています。 このディレクティブがリンカースクリプトで使用され、このオプションが有効になっている場合、リンカーのバージョンを含む文字列が現在の場所に挿入されます。

注:このリンカーコマンドラインでのオプションの場所は重要です。 これは、コマンドラインのこのオプションの後に続くリンカースクリプト、またはリンカーに組み込まれているリンカースクリプトにのみ影響します。

--disable-linker-version
"LINKER_VERSION" リンカースクリプトディレクティブを無効にして、バージョン文字列が挿入されないようにします。 これはデフォルトです。

--enable-non-contiguous-regions
入力セクションが、対応する出力セクションに収まらない場合にエラーを生成しないようにします。 リンカーは、入力セクションを後続の対応する出力セクションに割り当てようとし、十分な大きさの出力セクションがない場合にのみエラーを生成します。 これは、いくつかの連続していないメモリ領域が利用可能であり、入力セクションが特定の領域を必要としない場合に役立ちます。 入力セクションの評価順序は変更されません。 たとえば:

MEMORY {
MEM1 (rwx) : ORIGIN = 0x1000, LENGTH = 0x14
MEM2 (rwx) : ORIGIN = 0x1000, LENGTH = 0x40
MEM3 (rwx) : ORIGIN = 0x2000, LENGTH = 0x40
}
SECTIONS {
mem1 : { *(.data.*); } > MEM1
mem2 : { *(.data.*); } > MEM2
mem3 : { *(.data.*); } > MEM3
}

入力セクション:
.data.1: サイズ 8
.data.2: サイズ 0x10
.data.3: サイズ 4

結果:.data.1 は mem1 に、.data.2 と .data.3 は mem2 に割り当てられ、.data.3 は mem3 に収まるにもかかわらず、そうなりません。

このオプションは、INSERTステートメントと互換性がありません。なぜなら、入力セクションから出力セクションへのマッピング方法を変更するからです。

--enable-non-contiguous-regions-warnings
"--enable-non-contiguous-regions" がセクションのマッピングにおいて、予想外の一致を許可し、セクションがどの出力領域にも収まらないために静かに破棄される可能性がある場合に、警告を有効にします。

-e entry
--entry=entry
プログラムの実行開始に使用するシンボルを明示的に指定します。デフォルトのエントリーポイントの代わりに`entry`を使用します。`entry`という名前のシンボルがない場合、リンカーは`entry`を数値として解析し、その値をエントリーアドレスとして使用します(数値は10進数として解釈されます。先頭に`0x`を付けると16進数、先頭に`0`を付けると8進数になります)。i386 PEの場合、`entry`は元の関数名(先頭のアンダースコアおよび末尾の`stdcall @number`を削除したもの)にすることもできます。

--exclude-libs lib,lib,...
自動的にエクスポートしないシンボルを含むアーカイブライブラリのリストを指定します。ライブラリ名はカンマまたはコロンで区切ることができます。`--exclude-libs ALL`を指定すると、すべてのアーカイブライブラリ内のシンボルが自動エクスポートから除外されます。このオプションは、i386 PEをターゲットとするリンカーと、ELFをターゲットとするリンカーでのみ利用可能です。i386 PEの場合、`.def`ファイルに明示的にリストされているシンボルは、このオプションに関係なくエクスポートされます。ELFをターゲットとするリンカーの場合、このオプションで影響を受けるシンボルは非表示として扱われます。

--exclude-modules-for-implib module,module,...
自動的にエクスポートしないシンボルを含むオブジェクトファイルまたはアーカイブメンバーのリストを指定しますが、それらのシンボルは、リンク中に生成されるインポートライブラリに全体としてコピーされます。モジュール名はカンマまたはコロンで区切ることができ、リンカーがファイルを開くために使用するファイル名と正確に一致する必要があります。アーカイブメンバーの場合、これは単にメンバー名ですが、オブジェクトファイルの場合、指定された名前には、リンカーのコマンドラインで入力ファイルとして使用されたパスを含め、正確に一致する必要があります。このオプションは、i386 PEをターゲットとするリンカーでのみ利用可能です。`.def`ファイルに明示的にリストされているシンボルは、このオプションに関係なくエクスポートされます。

-E
--export-dynamic
--no-export-dynamic
動的にリンクされた実行ファイルを作成する場合、`-E`オプションまたは`--export-dynamic`オプションを使用すると、リンカーはすべてのシンボルを動的シンボルテーブルに追加します。動的シンボルテーブルは、実行時に動的オブジェクトから参照できるシンボルのセットです。

これらのオプション(またはデフォルトの動作を復元するために`--no-export-dynamic`オプション)を使用しない場合、動的シンボルテーブルには、リンクにリストされている動的オブジェクトのいずれかによって参照されるシンボルのみが含まれます。

`dlopen`を使用して、プログラムで定義されたシンボルを参照する必要がある動的オブジェクトをロードする場合、プログラム自体をリンクするときにこのオプションを使用する必要がある場合があります。

動的リストを使用して、出力形式がサポートしている場合に、動的シンボルテーブルに追加するシンボルを制御することもできます。`--dynamic-list`の説明を参照してください。

このオプションは、ELF をターゲットとするポートに固有です。PE ターゲットは、DLL または EXE からすべてのシンボルをエクスポートするための同様の機能を提供します。詳細については、以下に示す --export-all-symbols を参照してください。

^ -export-dynamic-symbol=glob 動的にリンクされた実行ファイルを作成する場合、glob に一致するシンボルが動的シンボルテーブルに追加されます。共有ライブラリを作成する場合、glob に一致するシンボルへの参照は、共有ライブラリ内の定義にバインドされません。このオプションは、共有ライブラリを作成し、-Bsymbolic または --dynamic-list が指定されていない場合、何も行いません。このオプションは、共有ライブラリをサポートする ELF プラットフォームでのみ意味を持ちます。

^ -export-dynamic-symbol-list=file ファイル内の各パターンに対して --export-dynamic-symbol を指定します。ファイルの形式は、スコープとノード名がないバージョンのノードと同じです。詳細については、「VERSION」を参照してください。

^ EB ビッグエンディアンオブジェクトをリンクします。これにより、デフォルトの出力形式が影響を受けます。

^ EL リトルエンディアンオブジェクトをリンクします。これにより、デフォルトの出力形式が影響を受けます。

^ f name ^ -auxiliary=name ELF 共有オブジェクトを作成する場合、内部の DT_AUXILIARY フィールドを指定された name に設定します。これにより、動的リンカーに、共有オブジェクトのシンボルテーブルを、共有オブジェクト name のシンボルテーブルに対する補助フィルタとして使用する必要があることが伝えられます。

後でこのフィルタオブジェクトに対してプログラムをリンクすると、プログラムを実行したときに動的リンカーは DT_AUXILIARY フィールドを認識します。動的リンカーがフィルタオブジェクトからシンボルを解決する場合、まず共有オブジェクト name に定義があるかどうかを確認します。定義がある場合は、フィルタオブジェクト内の定義ではなく、その定義が使用されます。共有オブジェクト name は存在する必要はありません。したがって、共有オブジェクト name は、デバッグまたはマシン固有のパフォーマンスのために、特定の関数の代替実装を提供するために使用できます。

このオプションは、複数回指定できます。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 実行ファイルまたは共有オブジェクトを作成する場合、実行ファイルまたは共有オブジェクトがアンロードされるときに、NAME を呼び出します。これは、DT_FINI を関数のアドレスに設定することで行われます。デフォルトでは、リンカーは "_fini" を呼び出す関数として使用します。

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

-G value
--gpsize=value

GP レジスタを使用して最適化するオブジェクトの最大サイズを size に設定します。これは、MIPS ELF などの、大規模および小規模のオブジェクトを異なるセクションに配置することをサポートするオブジェクトファイル形式でのみ意味があります。他のオブジェクトファイル形式の場合は無視されます。

-h name
-soname=name

ELF 共有オブジェクトを作成する場合、指定された名前を内部の DT_SONAME フィールドに設定します。実行ファイルが DT_SONAME フィールドを持つ共有オブジェクトでリンクされると、実行ファイルが実行されるときに、動的リンカーは、DT_SONAME フィールドで指定された共有オブジェクトを、リンカーに与えられたファイル名ではなく、ロードしようとします。

-i 段階的なリンクを実行します(-r オプションと同じ)。

-init=name

ELF 実行ファイルまたは共有オブジェクトを作成する場合、実行ファイルまたは共有オブジェクトがロードされるときに、NAME を呼び出します。これは、DT_INIT を関数のアドレスに設定することで行われます。デフォルトでは、リンカーは "_init" を呼び出す関数として使用します。

-l namespec
--library=namespec

namespec で指定されたアーカイブまたはオブジェクトファイルを、リンクするファイルのリストに追加します。このオプションは、任意の回数使用できます。namespec が :filename の形式の場合、ld はライブラリパスで filename というファイルを検索します。それ以外の場合は、ライブラリパスで libnamespec.a というファイルを検索します。

共有ライブラリをサポートするシステムでは、ld は libnamespec.a 以外のファイルも検索する場合があります。具体的には、ELF および SunOS システムでは、ld は、libnamespec.so というライブラリを libnamespec.a を検索する前に、ディレクトリで検索します。(慣例として、".so" 拡張子は共有ライブラリを示します)。ただし、この動作は :filename には適用されません。:filename は常に filename というファイルを指定します。

リンカーはアーカイブをコマンドラインで指定された場所でのみ一度検索します。アーカイブが、コマンドラインでアーカイブの前に表示されたオブジェクトで未定義だったシンボルを定義する場合、リンカーはアーカイブから適切なファイルを含めます。ただし、コマンドラインで後から表示されるオブジェクトで未定義のシンボルがある場合、リンカーはアーカイブをもう一度検索しません。

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

同じアーカイブをコマンドラインに複数回リストできます。

このタイプのアーカイブ検索は、Unix リンカーの標準です。ただし、AIX で ld を使用している場合は、AIX リンカーとは動作が異なることに注意してください。


-L searchdir
--library-path=searchdir

ldがアーカイブライブラリやld制御スクリプトを検索するパスのリストに、searchdirを追加します。このオプションは何度でも使用できます。ディレクトリは、コマンドラインで指定された順に検索されます。コマンドラインで指定されたディレクトリは、デフォルトのディレクトリよりも前に検索されます。すべての-Lオプションは、すべての-lオプションに適用されます。オプションの順序は関係ありません。-Lオプションは、-Tオプションが指定されていない限り、ldがリンカースクリプトを検索する方法には影響しません。

searchdirが「=」または「$SYSROOT」で始まる場合、このプレフィックスは、--sysrootオプションで制御されるsysrootプレフィックス、またはリンカが構成されたときに指定されたプレフィックスに置き換えられます。

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

パスは、リンカースクリプト内の「SEARCH_DIR」コマンドを使用して指定することもできます。この方法で指定されたディレクトリは、リンカースクリプトがコマンドラインに表示される時点で検索されます。

-m emulation

指定されたエミュレーションリンカをエミュレートします。使用可能なエミュレーションは、--verboseまたは-Vオプションでリスト表示できます。

-mオプションが使用されていない場合、エミュレーションは、定義されている場合は「LDEMULATION」環境変数から取得されます。

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

--remap-inputs=pattern=filename
--remap-inputs-file=file

これらのオプションを使用すると、リンカが入力ファイルを開く前に、入力ファイルの名前を変更できます。--remap-inputs=foo.o=bar.oオプションを使用すると、foo.oという名前のファイルをロードしようとするたびに、代わりにbar.oというファイルをロードしようとします。最初のファイル名にワイルドカードパターンを使用できます。したがって、--remap-inputs=foo*.o=bar.oは、foo*.oに一致するすべての入力ファイルをbar.oに名前変更します。

別の形式のオプションである--remap-inputs-file=filenameを使用すると、リマッピングをファイルから読み取ることができます。ファイル内の各行には、1つのリマッピングを含めることができます。空白の行は無視されます。ハッシュ文字(#)から行末までの部分はコメントと見なされ、無視されます。マッピングパターンは、空白または等号(=)文字でファイル名から区切ることができます。

これらのオプションは複数回指定できます。それらの内容は累積されます。リマッピングは、コマンドラインで発生した順序、またはファイルから取得した場合はファイル内の順序で処理されます。一致するものが見つかった場合、それ以上のチェックは行われません。

置換ファイル名が/dev/nullまたはNULの場合、リマッピングは実際に入力ファイルを無視します。これは、複雑なビルド環境から入力ファイルを削除して実験するのに便利な方法です。


このオプションは位置に依存し、コマンドラインでその後に続くファイル名にのみ影響します。したがって、次のコマンドは効果がありません。

ld foo.o --remap-inputs=foo.o=bar.o

一方、次のコマンドは foo.o という入力ファイルを bar.o に名前変更します。

ld --remap-inputs=foo.o=bar.o foo.o

注:これらのオプションは、リンカースクリプト内の INPUT ステートメントで参照されるファイルにも影響します。ただし、リンカースクリプトはコマンドライン全体が読み込まれた後に処理されるため、リマップオプションの位置は重要ではありません。

詳細オプションが有効になっている場合、一致するすべてのマッピングが報告されますが、リマップされたファイル名を表示するには、詳細オプションをコマンドラインで有効にする必要があります。

^ Map または --print-map オプションが有効になっている場合、リマップリストはマップ出力に含まれます。

-M
--print-map

リンクマップを標準出力に出力します。リンクマップは、次の情報を含むリンクに関する情報を提供します。

オブジェクトファイルがメモリにマップされる場所。

共通シンボルがどのように割り当てられるか。

リンクに含まれるすべてのアーカイブメンバーと、アーカイブメンバーが含められた原因となったシンボル。

シンボルに割り当てられた値。

注:値が、同じシンボルの以前の値への参照を含む式によって計算されるシンボルの場合、リンクマップに正しい結果が表示されないことがあります。これは、リンカが中間結果を破棄し、式の最終的な値のみを保持するためです。このような場合、リンカは最終的な値を角括弧で囲んで表示します。たとえば、リンカースクリプトに次の内容が含まれている場合:

foo = 1
foo = foo * 4
foo = foo + 8

^ M オプションを使用すると、リンクマップに次の出力が生成されます。

000000001                foo = 0x1
[0x0000000c]                foo = (foo * 0x4)
[0x0000000c]                foo = (foo + 0x8)

詳細については、「Expressions」を参照してください。

GNUプロパティがどのようにマージされるか。

リンカが入力.note.gnu.propertyセクションを1つの出力.note.gnu.propertyセクションにマージする場合、いくつかのプロパティが削除または更新されます。これらのアクションはリンクマップに報告されます。たとえば:

Removed property 0xc0000002 to merge foo.o (0x1) and bar.o (not found)

これは、foo.o(プロパティ 0xc0000002 の値は 0x1)と bar.o(プロパティ 0xc0000002 がない)のプロパティをマージするときに、出力からプロパティ 0xc0000002 が削除されることを示します。

Updated property 0xc0010001 (0x1) to merge foo.o (0x1) and bar.o (0x1)

これは、foo.o(プロパティ 0xc0010001 の値は 0x1)と bar.o(プロパティ 0xc0010001 の値は 0x1)のプロパティをマージするときに、出力のプロパティ 0xc0010001 の値が 0x1 に更新されることを示します。

一部のELFターゲットでは、--relaxによって挿入されたフィックスアップのリストが表示されます。

foo.o: Adjusting branch at 0x00000008 towards "far" in section .text

これは、foo.o0x00000008にある、.textセクション内のシンボル"far"をターゲットとするブランチが、トランポリンに置き換えられたことを示します。


--print-map-discarded
--no-print-map-discarded

リンクマップで破棄およびガーベッジコレクションされたセクションのリストを出力(または出力しない)。 デフォルトで有効。

--print-map-locals
--no-print-map-locals

リンクマップでローカルシンボルを出力(または出力しない)。ローカルシンボルは、名前の前に「(local)」というテキストが表示され、特定のセクション内のすべてのグローバルシンボルの後にリストされます。通常、.Lで始まる一時的なローカルシンボルは出力に含まれません。デフォルトで無効。

-n
--nmagic

セクションのページアラインメントをオフにし、共有ライブラリとのリンクを無効にします。出力形式がUnixスタイルのマジック番号をサポートしている場合、出力を「NMAGIC」としてマークします。

-N
--omagic

テキストセクションとデータセクションを読み取り可能かつ書き込み可能に設定します。また、データセグメントのページアラインメントをオフにし、共有ライブラリとのリンクを無効にします。出力形式がUnixスタイルのマジック番号をサポートしている場合、出力を「OMAGIC」としてマークします。注:書き込み可能なテキストセクションはPE-COFFターゲットで許可されていますが、Microsoftによって公開された形式仕様に準拠していません。

--no-omagic

このオプションは、-Nオプションのほとんどの効果を打ち消します。テキストセクションを読み取り専用に設定し、データセグメントをページアラインメントするように強制します。注:このオプションは、共有ライブラリとのリンクを有効にしません。これには、-Bdynamicを使用してください。

-o output
--output=output

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

注:リンカーは、出力ファイルに書き込みを開始する前に、それを削除します。エラーが発生してリンクが完了しなかった場合でも、削除します。

注:リンカーは、出力ファイル名が入力ファイルのいずれかの名前と一致しないことを確認しますが、それだけです。特に、出力ファイルがソースファイルやその他の重要なファイルを上書きする可能性がある場合でも、リンカーはエラーを報告しません。したがって、ビルドシステムでは、-oオプションをリンカーコマンドの最後のオプションとして使用することをお勧めします。たとえば、次のように考えてみてください。

ld -o $(EXE) $(OBJS)
ld $(OBJS) -o $(EXE)

EXE変数が何らかの理由で定義されていない場合、最初のリンカーコマンドは、オブジェクトファイルの1つ(OBJSリストの最初)を削除する可能性がありますが、2番目のリンカーコマンドはエラーメッセージを生成し、何も削除しません。

--dependency-file=depfile

depfileに依存関係ファイルを作成します。このファイルには、出力ファイルと、それを生成するために読み取られたすべての入力ファイルについて、「make」に適したルールが含まれています。出力は、-M -MPオプションを使用したコンパイラの出力に似ています。コンパイラの-MMのようなオプションはなく、「システムファイル」(これはリンカーでは明確に定義されていない概念であり、コンパイラの「システムヘッダー」とは異なります)を除外します。したがって、--dependency-fileからの出力は、常にインストール状態に固有であり、注意深く編集せずに配布されるmakefileにコピーすべきではありません。


-O level

level がゼロより大きい数値の場合、ld は出力を最適化します。これには時間がかかるため、最終的なバイナリでのみ有効にするのが適切です。現在、このオプションは ELF 共有ライブラリの生成にのみ影響します。今後の ld のリリースでは、このオプションがより多く使用される可能性があります。また、現在、このオプションの異なる非ゼロの値の間には、リンカーの動作に違いはありません。これも、今後のリリースで変更される可能性があります。

-plugin name

リンクプロセスにプラグインを含めます。name パラメータは、プラグインの絶対ファイル名です。通常、このパラメータは、リンク時最適化を使用する場合、コンパイラによって自動的に追加されますが、ユーザーは独自のプラグインを追加することもできます。

コンパイラによって生成されたプラグインの場所は、ar、nm、および ranlib プログラムがプラグインを検索する場所とは異なります。これらのコマンドがコンパイラベースのプラグインを使用できるようにするには、まず、それを ${libdir}/bfd-plugins ディレクトリにコピーする必要があります。すべての gcc ベースのリンカープラグインは後方互換性があるため、最新のものをコピーするだけで十分です。

--push-state

--push-state オプションを使用すると、入力ファイル処理を制御するフラグの現在の状態を保存し、対応する --pop-state オプションでそれらをすべて復元できます。

このオプションでカバーされるのは、-Bdynamic、-Bstatic、-dn、-dy、-call_shared、-non_shared、-static、-N、-n、--whole-archive、--no-whole-archive、-r、-Ur、--copy-dt-needed-entries、--no-copy-dt-needed-entries、--as-needed、--no-as-needed、および -a です。

このオプションのターゲットの 1 つは、pkg-config の仕様です。--libs オプションで使用すると、必要に応じてすべてのライブラリがリストされ、それらが常にリンクされる可能性があります。次のように返す方が適切です。

-Wl,--push-state,--as-needed -libone -libtwo -Wl,--pop-state

--pop-state

--push-state の効果を取り消し、入力ファイル処理を制御するフラグの以前の値を復元します。

-q
--emit-relocs

完全にリンクされた実行ファイルの再配置セクションとコンテンツを残します。ポストリンク分析および最適化ツールは、実行ファイルを正しく変更するために、この情報が必要になる場合があります。これにより、実行ファイルのサイズが大きくなります。

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

--force-dynamic

出力ファイルに動的セクションが含まれるように強制します。このオプションは、VxWorks ターゲットに固有です。

-r
--relocatable

再配置可能な出力を生成します。つまり、ld の入力として使用できる出力ファイルを生成します。これは、部分リンクとも呼ばれます。その結果、標準的な Unix マジック番号をサポートする環境では、このオプションは出力ファイルのマジック番号を "OMAGIC" にも設定します。このオプションが指定されていない場合、絶対ファイルが生成されます。C++ プログラムをリンクする場合、このオプションではコンストラクタへの参照は解決されないため、-Ur を使用します。

入力ファイルと出力ファイルが異なる形式の場合、部分的なリンクは、入力ファイルに再配置情報が含まれていない場合にのみサポートされます。異なる出力形式には、さらなる制限があります。たとえば、一部の「a.out」ベースの形式では、他の形式の入力ファイルとの部分的なリンクがまったくサポートされていません。

再配置可能な出力に、リンク時の最適化(LTO)が必要なコンテンツと、LTOが不要なコンテンツの両方が含まれている場合、.gnu_object_onlyセクションが作成され、再配置可能なオブジェクトファイルが含まれます。これは、LTOが不要なすべての再配置可能な入力に対して、-rを適用した場合と同じです。.gnu_object_onlyセクションを持つ再配置可能な入力を処理する場合、リンカーはその.gnu_object_onlyセクションを個別の入力として抽出します。

^ rは、異なる入力ファイルからのいくつかのセクションをグループ化するため、最終的な実行ファイルまたは共有ライブラリのコードサイズや局所性に悪影響を与える可能性があります。

このオプションは、-iと同じ動作をします。

-R filename
--just-symbols=filename

ファイル名からシンボル名とそのアドレスを読み込みますが、再配置も出力への含める処理も行いません。これにより、出力ファイルから他のプログラムで定義されたメモリの絶対位置をシンボリックに参照できるようになります。このオプションは、複数回使用できます。

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

--rosegment
--no-rosegment

読み取り専用でコードではないセクションが1つだけ作成されるようにします。-z separate-codeオプションと組み合わせて使用​​する場合にのみ有効です。結果として得られるバイナリは、-z separate-codeを単独で使用した場合よりも小さくなります。このオプションが指定されていない場合、または--no-rosegmentが指定された場合、-z separate-codeオプションは2つの読み取り専用セクション(コードセクションの前と後)を作成します。

オプションの名前は誤解を招きやすいですが、リンカーがLLDおよびGOLDリンカーと互換性を持つように選択されています。

これらのオプションは、ELFターゲットでのみサポートされます。

-s
--strip-all

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

-S
--strip-debug

デバッガーのシンボル情報(ただし、すべてのシンボルではない)を出力ファイルから省略します。

--strip-discarded
--no-strip-discarded

破棄されたセクションで定義されたグローバルシンボルを省略するか(デフォルトで有効)、省略しないかを指定します。

-plugin-save-temps

プラグインの「一時的な」中間ファイルを永続的に保存します。

-t
--trace

ldが処理する入力ファイルの名前を出力します。-tを2回指定すると、アーカイブ内のメンバーも出力されます。-tの出力は、リンカーのバグ報告のために、関連するすべてのオブジェクトファイルとスクリプトのリストを生成する場合に役立ちます。


-T scriptfile
--script=scriptfile

リンカースクリプトとして scriptfile を使用します。このスクリプトは、スクリプトに "INSERT" が含まれていない限り、ld のデフォルトのリンカースクリプトを置き換えます。したがって、commandfile には、出力ファイルを記述するために必要なすべてのものが指定されている必要があります。

scriptfile が現在のディレクトリに存在しない場合、ld は、-L オプションで指定されたディレクトリで scriptfile を検索します。

-T オプションの前に表示されるコマンドラインオプションは、スクリプトに影響を与える可能性がありますが、その後に表示されるコマンドラインオプションは影響を与えません。

複数の -T オプションがある場合、それらが現在のスクリプトを拡張する場合は累積されます。それ以外の場合は、最後の、拡張しない -T オプションが使用されます。

リンカースクリプトを指定する方法は他にもあります。以下を参照してください。

-dT scriptfile
--default-script=scriptfile

リンカースクリプトとして scriptfile を使用します。

このオプションは、--script オプションと似ていますが、スクリプトの処理は、残りのコマンドラインが処理されるまで遅延されます。これにより、--default-script オプションの後に配置されたコマンドラインオプションが、リンカースクリプトの動作に影響を与えることができ、これは、リンカーのコマンドラインをユーザーが直接制御できない場合に重要になります(例:コマンドラインが別のツール(gcc など)によって構築されている場合)。

-u symbol
--undefined=symbol

シンボルを未定義のシンボルとして出力ファイルに強制的に入力します。これにより、たとえば、標準ライブラリから追加のモジュールをリンクするようにトリガーできます。-u は、異なるオプション引数で繰り返して、追加の未定義シンボルを入力できます。このオプションは、リンカースクリプトの "EXTERN" コマンドと同等です。

このオプションを使用して、追加のモジュールをリンクする必要があり、シンボルが未定義のままにしておくのがエラーである場合は、代わりに --require-defined オプションを使用する必要があります。

--require-defined=symbol

シンボルが出力ファイルで定義されていることを要求します。このオプションは、--undefined オプションと同じですが、シンボルが出力ファイルで定義されていない場合、リンカーはエラーを出力して終了します。同じ効果は、リンカースクリプトで "EXTERN"、"ASSERT"、および "DEFINED" を組み合わせて使用​​することで実現できます。このオプションを複数回使用して、追加のシンボルを要求できます。

-Ur コンストラクターまたはデストラクタを使用しないプログラム、または ELF ベースのシステムの場合、このオプションは -r と同等です。つまり、出力ファイルは、ld の入力として使用できる再配置可能なファイルになります。ただし、他のバイナリの場合は、-Ur オプションは -r に似ていますが、コンストラクターとデストラクタへの参照も解決します。

-r と -Ur が異なる動作をするシステムの場合、-Ur でリンクされたファイルを -Ur で再度リンクすることはできません。コンストラクターテーブルが構築されると、後から追加することはできません。-Ur は最後の部分的なリンクでのみ使用し、他の場合は -r を使用します。


--orphan-handling=MODE

孤立セクションの処理方法を制御します。孤立セクションとは、リンカースクリプトで明示的に参照されていないセクションです。

MODE には、次のいずれかの値を指定できます。

"place"

孤立セクションは、孤立セクションで説明されている戦略に従って、適切な出力セクションに配置されます。--unique オプションも、セクションの配置方法に影響します。

"discard"

すべての孤立セクションは、/DISCARD/ セクションに配置することで破棄されます。

"warn"

リンカは、孤立セクションを "place" のように配置し、警告も発行します。

"error"

リンカは、孤立セクションが見つかった場合にエラーで終了します。

--orphan-handling が指定されていない場合のデフォルト値は "place" です。

--unique[=SECTION]

一致する入力セクションごとに、またはオプションのワイルドカード SECTION 引数がない場合は、すべての孤立入力セクションに対して、個別の出力セクションを作成します。孤立セクションとは、リンカースクリプトで明示的に参照されていないセクションです。このオプションをコマンドラインで複数回使用できます。これは、同じ名前の入力セクションを通常どおりマージするのではなく、リンカースクリプト内の出力セクションの割り当てを上書きします。

-v
--version
-V ld のバージョン番号を表示します。-V オプションは、サポートされているエミュレーションもリスト表示します。[オプション](#オプション)、[コマンドラインオプション](#コマンドラインオプション)の説明にあるように、--enable-linker-version を使用してリンカのバージョン文字列をバイナリに挿入することもできます。

-x
--discard-all

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

-X
--discard-locals

すべての一時的なローカルシンボルを削除します。(これらのシンボルは、システム固有のローカルラベルのプレフィックス (通常は ELF システムの場合は .L、従来の a.out システムの場合は L) で始まります。)

-y symbol
--trace-symbol=symbol

シンボルが出現するリンクされたファイルの各名前を出力します。このオプションは、任意の回数指定できます。多くのシステムでは、先頭にアンダースコアを付ける必要があります。

このオプションは、リンク時に未定義のシンボルがあり、その参照元がわからない場合に役立ちます。

-Y path

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

-z keyword

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

call-nop=prefix-addr
call-nop=suffix-nop
call-nop=prefix-byte
call-nop=suffix-byte

間接呼び出しを、ローカルで定義された関数 foo の GOT スロットを介して変換するときに使用する 1 バイトの "NOP" パディングを指定します。call-nop=prefix-addr は "0x67 call foo" を生成します。call-nop=suffix-nop は "call foo 0x90" を生成します。call-nop=prefix-byte は "byte call foo" を生成します。call-nop=suffix-byte は "call foo byte" を生成します。i386 および x86_64 でサポートされています。

cet-report=none
cet-report=warning
cet-report=error

入力 .note.gnu.property セクションの GNU_PROPERTY_X86_FEATURE_1_IBT および GNU_PROPERTY_X86_FEATURE_1_SHSTK プロパティが不足している場合に、どのように報告するかを指定します。cet-report=none はデフォルトであり、リンカは入力ファイルのプロパティが不足しているかどうかを報告しません。cet-report=warning は、リンカが入力ファイルのプロパティが不足している場合に警告を発行するようにします。cet-report=error は、リンカが入力ファイルのプロパティが不足している場合にエラーを発行するようにします。ただし、ibt は GNU_PROPERTY_X86_FEATURE_1_IBT プロパティの不足しているプロパティの報告を停止し、shstk は GNU_PROPERTY_X86_FEATURE_1_SHSTK プロパティの不足しているプロパティの報告を停止します。Linux/i386 および Linux/x86_64 でサポートされています。


combreloc
nocombreloc

複数の動的再配置セクションを結合し、ソートすることで、動的シンボル参照のキャッシュを改善します。nocombreloc の場合は行わないでください。

common
nocommon

再配置可能なリンク中に、STT_COMMON 型の共通シンボルを生成します。nocommon の場合は、STT_OBJECT 型を使用します。

common-page-size=value

最も一般的に使用されるページサイズを value に設定します。システムのページサイズがこの値である場合、メモリイメージのレイアウトを最適化して、メモリページの数を最小限に抑えます。

defs

通常のオブジェクトファイルからの未解決のシンボル参照を報告します。これは、リンカーがシンボルを持たない共有ライブラリを作成する場合でも行われます。このオプションは、-z undefs の逆です。

dynamic-undefined-weak
nodynamic-undefined-weak

動的オブジェクトを構築する際に、未定義の弱いシンボルを動的にします。ただし、シンボルの可視性またはバージョン管理によってローカルに強制されている場合は、動的にしません。dynamic-undefined-weak の場合は動的にします。どちらのオプションも指定されていない場合、ターゲットはどちらかのオプションを有効にするか、または未定義の弱いシンボルの一部を動的にするように選択する場合があります。すべてのターゲットがこれらのオプションをサポートしているわけではありません。

execstack

オブジェクトを実行可能スタックを必要とするものとしてマークします。

global

このオプションは、共有オブジェクトを構築する場合にのみ意味があります。この共有オブジェクトによって定義されたシンボルを、後続にロードされるライブラリのシンボル解決で使用できるようにします。

globalaudit

このオプションは、動的実行ファイルを構築する場合にのみ意味があります。「DT_FLAGS_1」動的タグの「DF_1_GLOBAUDIT」ビットを設定することにより、実行ファイルがグローバル監査を必要とすることを示します。グローバル監査には、--depaudit または -P コマンドラインオプションを介して定義された監査ライブラリを、アプリケーションによってロードされたすべての動的オブジェクトに対して実行する必要があります。

ibtplt

Intel 間接分岐追跡(IBT)を有効にした PLT エントリを生成します。Linux/i386 および Linux/x86_64 でサポートされています。

ibt

^ note.gnu.property セクションに GNU_PROPERTY_X86_FEATURE_1_IBT を生成し、IBT との互換性を示します。これにより、ibtplt も有効になります。Linux/i386 および Linux/x86_64 でサポートされています。

indirect-extern-access
noindirect-extern-access

^ note.gnu.property セクションに GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS を生成し、オブジェクトファイルが正規の関数ポインタを必要とし、コピー再配置で使用できないことを示します。このオプションは、noextern-protected-data および nocopyreloc も暗示します。i386 および x86-64 でサポートされています。


noindirect-extern-access   GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS    を
.note.gnu.property セクションから削除します。

initfirst
このオプションは、共有オブジェクトをビルドする場合にのみ意味を持ちます。このオプションは、
オブジェクトの実行時初期化が、同時にプロセスにロードされた他のオブジェクトの実行時初期化よりも前に行われるようにオブジェクトをマークします。同様に、オブジェクトの実行時終了処理は、他のオブジェクトの実行時終了処理よりも後に行われます。

interpose
動的ローダーがシンボル検索順序を変更し、この共有ライブラリのシンボルが、同様にマークされていない他の共有ライブラリのシンボルよりも優先されるように指定します。

unique
nounique
共有ライブラリまたはその他の動的にロード可能なELFオブジェクトを生成するときに、これを一度だけロードされ、デフォルトではメインのネームスペースにのみロードされるようにマークします("dlmopen"を使用する場合)。これは主に、libc、libpthreadなどの基本的なライブラリをマークするために使用されます。これらのライブラリは、通常、それら自体が唯一のインスタンスである場合にのみ正常に機能します。この動作は、"dlmopen"呼び出しによってオーバーライドでき、監査ライブラリなどの特定のロードメカニズムには適用されません。

lam-u48
.note.gnu.property セクションに GNU\_PROPERTY\_X86\_FEATURE\_1\_LAM\_U48 を生成して、
Intel LAM_U48 との互換性を示します。Linux/x86_64 でサポートされます。

lam-u57
.note.gnu.property セクションに GNU\_PROPERTY\_X86\_FEATURE\_1\_LAM\_U57 を生成して、
Intel LAM_U57 との互換性を示します。Linux/x86_64 でサポートされます。

lam-u48-report=none
lam-u48-report=warning
lam-u48-report=error
入力 .note.gnu.property セクションに欠落している GNU\_PROPERTY\_X86\_FEATURE\_1\_LAM\_U48 プロパティをどのように報告するかを指定します。
lam-u48-report=none (デフォルト) は、リンカーが入力ファイル内の欠落しているプロパティを報告しないようにします。lam-u48-report=warning は、リンカーが入力ファイル内の欠落しているプロパティについて警告を発するようにします。lam-u48-report=error は、リンカーが入力ファイル内の欠落しているプロパティについてエラーを発するようにします。Linux/x86_64 でサポートされます。

lam-u57-report=none
lam-u57-report=warning
lam-u57-report=error
入力 .note.gnu.property セクションに欠落している GNU\_PROPERTY\_X86\_FEATURE\_1\_LAM\_U57 プロパティをどのように報告するかを指定します。
lam-u57-report=none (デフォルト) は、リンカーが入力ファイル内の欠落しているプロパティを報告しないようにします。lam-u57-report=warning は、リンカーが入力ファイル内の欠落しているプロパティについて警告を発するようにします。lam-u57-report=error は、リンカーが入力ファイル内の欠落しているプロパティについてエラーを発するようにします。Linux/x86_64 でサポートされます。

lam-report=none
lam-report=warning
lam-report=error
入力 .note.gnu.property セクションに欠落している GNU\_PROPERTY\_X86\_FEATURE\_1\_LAM\_U48 および
GNU\_PROPERTY\_X86\_FEATURE\_1\_LAM\_U57 プロパティをどのように報告するかを指定します。
lam-report=none (デフォルト) は、リンカーが入力ファイル内の欠落しているプロパティを報告しないようにします。lam-report=warning は、リンカーが入力ファイル内の欠落しているプロパティについて警告を発するようにします。lam-report=error は、リンカーが入力ファイル内の欠落しているプロパティについてエラーを発するようにします。Linux/x86_64 でサポートされます。

lazy

実行ファイルまたは共有ライブラリを生成する際に、動的リンカに、関数の呼び出し解決を、ロード時に行うのではなく、関数が呼び出された時点で遅延して行うように指示します(遅延バインディング)。遅延バインディングはデフォルトです。

loadfltr

オブジェクトのフィルタを、実行時に直ちに処理するように指定します。

max-page-size=value

サポートする最大メモリページサイズをvalueに設定します。

mark-plt
nomark-plt

PLTエントリに動的タグDT_X86_64_PLT、DT_X86_64_PLTSZ、およびDT_X86_64_PLTENTでマークします。 このオプションは、R_X86_64_JUMP_SLOTリロケーションのr_addendフィールドにゼロ以外の値を格納するため、生成された実行ファイルと共有ライブラリは、古いバージョンのglibcなどの動的リンカと互換性がありません。これらの動的リンカは、R_X86_64_GLOB_DATおよびR_X86_64_JUMP_SLOTリロケーションのr_addendフィールドを無視する変更が適用されていません。R_X86_64_JUMP_SLOTリロケーションのr_addendフィールドを無視しないためです。x86_64でサポートされます。

muldefs

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

nocopyreloc

リンカによって生成される、共有ライブラリで定義された変数の代わりに使用される.dynbss変数の生成を無効にします。これにより、動的テキストリロケーションが発生する可能性があります。

nodefaultlib

このオブジェクトの依存関係に対して、動的ローダがデフォルトのライブラリ検索パスを無視するように指定します。

nodelete

オブジェクトが実行時にアンロードされないように指定します。

nodlopen

オブジェクトが「dlopen」で利用できないように指定します。

nodump

オブジェクトが「dldump」によってダンプできないように指定します。

noexecstack

オブジェクトが実行可能スタックを必要としないようにマークします。

noextern-protected-data

共有ライブラリをビルドする際に、保護されたデータシンボルを外部シンボルとして扱わないようにします。このオプションは、リンカバックエンドのデフォルトをオーバーライドします。これは、コンパイラによって生成された、保護されたデータシンボルに対する誤ったリロケーションに対処するために使用できます。共有ライブラリの保護されたデータシンボルに対する更新は、別のモジュールからは見えません。i386およびx86-64でサポートされます。

noreloc-overflow

リロケーションオーバーフローチェックを無効にします。実行時に動的リロケーションオーバーフローが発生しない場合に、このチェックを無効にすることができます。x86_64でサポートされます。

memory-seal
nomemory-seal

実行ファイルまたは共有ライブラリに対し、すべてのPT_LOADセグメントを、それ以上の操作(保護フラグの変更、セグメントサイズの変更、マッピングの削除など)を防ぐためにシールするように指示します。これは、システムサポートが必要なセキュリティ強化です。これにより、.note.gnu.propertyセクションにGNU_PROPERTY_MEMORY_SEALが生成されます。

now

実行ファイルまたは共有ライブラリを生成する際に、動的リンカに、プログラムが開始されたとき、または共有ライブラリがdlopenによってロードされたときに、すべてのシンボルを解決するように指示します。関数の呼び出し解決を、関数が最初に呼び出される時点で遅延して行うのではなく、実行します。


origin

オブジェクトが $ORIGIN ハンドリングをパスで使用することを指定します。

pack-relative-relocs
nopack-relative-relocs

位置独立実行ファイルおよび共有ライブラリで、コンパクトな相対リロケーションを生成します。 DT_RELRDT_RELRSZ、および DT_RELRENT エントリを動的セクションに追加します。 位置依存実行ファイルおよびリロケータブル出力の場合は無視されます。 ^ opack-relative-relocs がデフォルトであり、コンパクトな相対リロケーションを無効にします。 GNU C ライブラリに対してリンクする場合、出力に共有 C ライブラリに対する GLIBC_ABI_DT_RELR シンボルバージョン依存関係が追加されます。 i386 および x86-64 でサポートされます。

relro
norelro

オブジェクトに ELF PT_GNU_RELRO セグメントヘッダーを作成します。 これは、サポートされている場合、リロケーション後に読み取り専用にすべきメモリセグメントを指定します。 commonpage-size をシステムページサイズよりも小さい値に指定すると、この保護が無効になります。 norelro を指定すると、ELF PT_GNU_RELRO セグメントを作成しません。

report-relative-reloc

リンカーによって生成された動的相対リロケーションを報告します。 Linux/i386 および Linux/x86_64 でサポートされます。

sectionheader
nosectionheader

セクションヘッダーを生成します。 nosectionheader を使用すると、セクションヘッダーは生成されません。 sectionheader がデフォルトです。

separate-code
noseparate-code

オブジェクトに別のコード PT_LOAD セグメントヘッダーを作成します。 これは、命令のみを含むメモリセグメントであり、他のデータとは完全に分離されたページに存在する必要があります。 noseparate-code を使用すると、別のコード PT_LOAD セグメントは作成されません。

shstk

^ note.gnu.property セクションに GNU_PROPERTY_X86_FEATURE_1_SHSTK を生成して、Intel Shadow Stackとの互換性を示します。 Linux/i386 および Linux/x86_64 でサポートされます。

stack-size=value

ELF PT_GNU_STACK セグメントのスタックサイズを指定します。 ゼロを指定すると、デフォルトのゼロ以外のサイズの PT_GNU_STACK セグメントの作成がオーバーライドされます。

start-stop-gc
nostart-stop-gc

^ -gc-sections が有効な場合、保持されたセクションから __start_SECNAME または __stop_SECNAME への参照は、SECNAME が C 識別子として表現可能であり、__start_SECNAME または __stop_SECNAME がリンカーによって合成された場合に、入力セクション SECNAME のすべても保持されます。 -z start-stop-gc はこの効果を無効にし、特別な合成されたシンボルが定義されていないかのようにセクションをガベージコレクトできるようにします。 -z start-stop-gc は、オブジェクトファイルまたはリンカースクリプト内の __start_SECNAME または __stop_SECNAME の定義には影響しません。そのような定義は、リンカーが合成された __start_SECNAME または __stop_SECNAME を提供するのを防ぎ、したがってガベージコレクションによる特別な処理も行われません。

start-stop-visibility=value

合成された __start_SECNAME および __stop_SECNAME シンボルの ELF シンボル可視性を指定します。 value は、defaultinternalhidden、または protected のいずれかでなければなりません。 -z start-stop-visibility オプションが指定されていない場合、互換性のために protected が使用されます。ただし、新しいプログラムと共有ライブラリでは、-z start-stop-visibility=hidden を使用することを強くお勧めします。これにより、これらのシンボルが共有オブジェクト間でエクスポートされるのを防ぎ、通常はそれを意図していません。


テキスト
テキストなし
テキストオフ
DT\_TEXTREL が設定されている場合、つまり、位置に依存しない、または共有オブジェクトに読み取り専用セクションに動的リロケーションが含まれている場合にエラーを報告します。テキストなしまたはテキストオフの場合は、エラーを報告しないでください。

undefs
通常オブジェクトファイルからの未解決のシンボル参照を、実行ファイルの作成時、または共有ライブラリの作成時に報告しないようにします。このオプションは、-z defs の逆のオプションです。

unique-symbol
nounique-symbol
シンボル文字列テーブル内の重複するローカルシンボル名を回避します。unique-symbol を使用すると、重複するローカルシンボル名に「.number」が追加されます。nounique-symbol がデフォルトです。

x86-64-baseline
x86-64-v2
x86-64-v3
x86-64-v4
x86-64 ISA レベルを .note.gnu.property セクションで指定します。x86-64-baseline は「GNU\_PROPERTY\_X86\_ISA\_1\_BASELINE」を生成します。x86-64-v2 は「GNU\_PROPERTY\_X86\_ISA\_1\_V2」を生成します。x86-64-v3 は「GNU\_PROPERTY\_X86\_ISA\_1\_V3」を生成します。x86-64-v4 は「GNU\_PROPERTY\_X86\_ISA\_1\_V4」を生成します。Linux/i386 および Linux/x86\_64 でサポートされます。

isa-level-report=none
isa-level-report=all
isa-level-report=needed
isa-level-report=used
x86-64 ISA レベルの入力リロケータブルファイルでの報告方法を指定します。isa-level-report=none (デフォルト) は、リンカーが入力ファイル内の x86-64 ISA レベルを報告しないようにします。isa-level-report=all は、リンカーが入力ファイル内の必要な x86-64 ISA レベルと使用されている x86-64 ISA レベルを報告するようにします。isa-level-report=needed は、リンカーが入力ファイル内の必要な x86-64 ISA レベルを報告するようにします。isa-level-report=used は、リンカーが入力ファイル内の使用されている x86-64 ISA レベルを報告するようにします。Linux/i386 および Linux/x86\_64 でサポートされます。

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

--gnu-tls-tag
--no-gnu-tls-tag
入力リロケータブルオブジェクトファイルが「___tls\_get\_addr」を呼び出す場合、glibc に対してリンクするときに、出力プログラムと共有ライブラリに「GLIBC\_ABI\_GNU\_TLS」バージョンタグの依存関係を追加します。出力は、実行時に「GLIBC\_ABI\_GNU\_TLS」バージョンタグを定義していない glibc に対してロードおよび実行しようとすると失敗します。リンカーのビルド時に --disable-gnu-tls-tag 構成オプションで無効にされていない限り、オプションが指定されていない場合、入力に「___tls\_get\_addr」呼び出しがあり、libc.so が「GLIBC\_ABI\_GNU\_TLS」バージョンタグを定義している場合、リンカーは「GLIBC\_ABI\_GNU\_TLS」バージョンタグの依存関係を追加します。Linux/i386 でサポートされます。

--gnu2-tls-tag
--no-gnu2-tls-tag
入力リロケータブルオブジェクトファイルに「R\_386\_TLS\_DESC\_CALL」または「R\_X86\_64\_TLSDESC\_CALL」リロケーションがある場合、glibc に対してリンクするときに、出力プログラムと共有ライブラリに「GLIBC\_ABI\_GNU2\_TLS」バージョンタグの依存関係を追加します。出力は、実行時に「GLIBC\_ABI\_GNU2\_TLS」バージョンタグを定義していない glibc に対してロードおよび実行しようとすると失敗します。リンカーのビルド時に --disable-gnu2-tls-tag 構成オプションで無効にされていない限り、オプションが指定されていない場合、入力に「R\_386\_TLS\_DESC\_CALL」または「R\_X86\_64\_TLSDESC\_CALL」リロケーションがあり、libc.so が「GLIBC\_ABI\_GNU2\_TLS」バージョンタグを定義している場合、リンカーは「GLIBC\_ABI\_GNU2\_TLS」バージョンタグの依存関係を追加します。Linux/i386 および Linux/x86\_64 でサポートされます。

-( archives -)
--start-group archives --end-group

アーカイブは、アーカイブファイルのリストである必要があります。明示的なファイル名、または -l オプションのいずれかです。

指定されたアーカイブは、新しい未定義の参照が作成されなくなるまで、繰り返し検索されます。通常、アーカイブはコマンドラインで指定された順に一度だけ検索されます。アーカイブ内のシンボルが、コマンドラインで後続に表示されるアーカイブ内のオブジェクトによって参照される未定義のシンボルを解決するために必要な場合、リンカーはその参照を解決できません。アーカイブをグループ化することで、それらすべてのアーカイブが繰り返し検索され、可能な限りすべての参照が解決されます。

このオプションを使用すると、パフォーマンスに大きな影響があります。避けられない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タグは、通常のオブジェクトファイルから、その時点でリンクにおいて、弱い以外の未定義のシンボル参照を満たすライブラリに対してのみ発行されます。または、ライブラリが他の必要なライブラリのDT_NEEDEDリストに見つからない場合、別の必要な動的ライブラリから、弱い以外の未定義のシンボル参照に対してのみ発行されます。コマンドラインでそのライブラリの後に表示されるオブジェクトファイルまたはライブラリは、そのライブラリが必要かどうかには影響しません。これは、アーカイブからオブジェクトファイルを抽出するためのルールに似ています。--no-as-neededは、デフォルトの動作を復元します。


注: Linux ベースのシステムでは、`--as-needed` オプションは、`--rpath` および `--rpath-link` オプションの動作にも影響を与えます。詳細は、`--rpath-link` の説明を参照してください。

`--add-needed`
`--no-add-needed`
これらの 2 つのオプションは、`--as-needed` および `--no-as-needed` オプションとの名前が似ているため、非推奨になりました。これらは、`--copy-dt-needed-entries` および `--no-copy-dt-needed-entries` に置き換えられました。

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

`-Bdynamic`
`-dy`
`-call_shared`
動的ライブラリに対してリンクします。これは、共有ライブラリがサポートされているプラットフォームでのみ意味を持ちます。通常、このようなプラットフォームではこれがデフォルトです。このオプションの異なるバリエーションは、さまざまなシステムとの互換性のために用意されています。このオプションをコマンドラインで複数回使用できます。これは、それに続く `-l` オプションのライブラリ検索に影響します。

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

`-Bstatic`
`-dn`
`-non_shared`
`-static`
共有ライブラリに対してリンクしない。これは、共有ライブラリがサポートされているプラットフォームでのみ意味を持ちます。このオプションの異なるバリエーションは、さまざまなシステムとの互換性のために用意されています。このオプションをコマンドラインで複数回使用できます。これは、それに続く `-l` オプションのライブラリ検索に影響します。このオプションは `-shared` と組み合わせて使用できます。その場合、共有ライブラリが作成されますが、そのライブラリの外部参照はすべて、静的ライブラリからエントリを読み込むことによって解決される必要があります。

`-Bsymbolic`
共有ライブラリを作成するときに、グローバルシンボルへの参照を、共有ライブラリ内の定義(存在する場合)にバインドします。通常、共有ライブラリに対してリンクされたプログラムは、共有ライブラリ内の定義をオーバーライドできます。このオプションは、共有ライブラリをサポートする ELF プラットフォームでのみ意味を持ちます。

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

`-Bno-symbolic`
このオプションは、以前に指定された `-Bsymbolic` および `-Bsymbolic-functions` を取り消すことができます。

`--dynamic-list=dynamic-list-file`
リンカーに動的リストファイルのパスを指定します。これは通常、共有ライブラリを作成するときに、共有ライブラリ内の定義にバインドされるべきではないグローバルシンボルのリストを指定するため、または動的にリンクされた実行可能ファイルを作成するときに、実行可能ファイルのシンボルテーブルに追加されるべきシンボルのリストを指定するために使用されます。このオプションは、共有ライブラリをサポートする ELF プラットフォームでのみ意味を持ちます。

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

--dynamic-list-data

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

--dynamic-list-cpp-new

C++ の operator new および delete 用の組み込み動的リストを提供します。主に、 共有 libstdc++ を構築する場合に役立ちます。

--dynamic-list-cpp-typeinfo

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

--check-sections
--no-check-sections

リンカーに対して、セクションアドレスが割り当てられた後にセクションアドレスの重複がないか確認しないように指示します。 通常、リンカーはこのチェックを実行し、重複が見つかった場合は適切なエラーメッセージを出力します。 リンカーは、オーバーレイ内のセクションについて認識しており、それに対応した処理を行います。 デフォルトの動作は、コマンドラインスイッチ --check-sections を使用して復元できます。 セクションの重複は、通常、リロケータブルリンクではチェックされません。 その場合でも、--check-sections オプションを使用することで、チェックを強制できます。

--copy-dt-needed-entries
--no-copy-dt-needed-entries

このオプションは、コマンドラインで指定された ELF 動的ライブラリ内の DT_NEEDED タグによって参照される動的ライブラリの処理に影響します。 通常、リンカーは、入力動的ライブラリ内の DT_NEEDED タグで参照される各ライブラリに対して、出力バイナリに DT_NEEDED タグを追加しません。 ただし、コマンドラインで --copy-dt-needed-entries を指定すると、その後に続くすべての動的ライブラリに対して、DT_NEEDED エントリが追加されます。 デフォルトの動作は、--no-copy-dt-needed-entries を使用して復元できます。

このオプションは、動的ライブラリ内のシンボルの解決にも影響します。 --copy-dt-needed-entries を指定すると、コマンドラインで指定された動的ライブラリは再帰的に検索され、DT_NEEDED タグをたどって他のライブラリにアクセスし、出力バイナリに必要なシンボルを解決します。 ただし、デフォルトの設定では、その後に続く動的ライブラリの検索は、その動的ライブラリ自体で停止します。 DT_NEEDED リンクはトラバースされず、シンボルは解決されません。

--cref

クロスリファレンステーブルを出力します。リンカーマップファイルが生成されている場合、クロスリファレンステーブルはマップファイルに出力されます。 そうでない場合は、標準出力に出力されます。

テーブルの形式は、意図的に単純化されており、必要に応じてスクリプトで簡単に処理できるようにします。シンボルは名前でソートして出力されます。 各シンボルについて、ファイル名のリストが表示されます。シンボルが定義されている場合、リストの最初のファイルは定義の場所です。 シンボルが共通の値として定義されている場合、この値が存在するすべてのファイルが次に表示されます。最後に、シンボルを参照するすべてのファイルがリストされます。


--ctf-variables
--no-ctf-variables

CTFデバッグ情報形式は、プログラム内で見つかり、シンボルテーブルに表示されない変数の名前と型をエンコードするセクションをサポートしています。これらの変数は、従来のデバッガーではアドレスで参照できないため、型と名前のスペースは通常無駄になります。--ctf-variablesは、そのようなセクションの生成を有効にします。デフォルトの動作は、--no-ctf-variablesで復元できます。

--ctf-share-types=method

CTFで翻訳ユニット間で型を共有する方法を調整します。

share-unconflicted

曖昧な定義を持たないすべての型を、デバッガーが簡単にアクセスできるように、共有辞書に配置します。たとえ1つの翻訳ユニットでのみ出現する場合でも。これがデフォルトです。

share-duplicated

複数の翻訳ユニットに存在する型のみを共有辞書に配置します。1つの定義しかない型は、翻訳ユニットごとの辞書に配置されます。複数の翻訳ユニットに曖昧な定義がある型は、常に翻訳ユニットごとの辞書に配置されます。これにより、CTFのサイズが大きくなる傾向がありますが、共有辞書内のCTFの量を減らすことができます。非常に大規模なプロジェクトの場合、これによりCTFの読み込みが高速化され、実行時のCTFコンシューマーでのメモリ使用量が削減される可能性があります。

--no-define-common

このオプションは、共通シンボルへのアドレスの割り当てを禁止します。スクリプトコマンド "INHIBIT_COMMON_ALLOCATION" は同じ効果があります。

--no-define-commonオプションにより、共通シンボルへのアドレス割り当ての決定と、出力ファイルタイプの選択を分離できます。そうでない場合、リロケータブルでない出力タイプは、共通シンボルにアドレスを割り当てることを強制します。--no-define-commonを使用すると、共有ライブラリから参照される共通シンボルは、メインプログラムでのみアドレスを割り当てられます。これにより、共有ライブラリ内の未使用の重複スペースが排除され、実行時のシンボル解決のための特殊な検索パスを持つ多くの動的モジュールがある場合に、誤った重複への解決が起こる可能性もなくなります。

--force-group-allocation

このオプションにより、リンカーはセクショングループのメンバーを通常の入力セクションのように配置し、セクショングループを削除します。これは、最終リンクのデフォルトの動作ですが、このオプションを使用して、リロケータブルリンク (-r) の動作を変更できます。スクリプトコマンド "FORCE_GROUP_ALLOCATION" は同じ効果があります。

--defsym=symbol=expression

出力ファイルにグローバルシンボルを作成し、式によって与えられる絶対アドレスを格納します。コマンドラインで複数のシンボルを定義する必要がある場合は、このオプションを必要な回数だけ使用できます。このコンテキストでは、限られた形式の算術演算がサポートされています。16進数の定数、既存のシンボルの名前、または16進数の定数またはシンボルを加算または減算するために "+" および "-" を使用できます。より複雑な式が必要な場合は、スクリプトからリンカーコマンド言語を使用することを検討してください。注: シンボル、等号 ("=") 、および式の間には空白を入れないでください。


リンカーは --defsym 引数と -T 引数を順番に処理し、--defsym-T より前に配置すると、リンカースクリプト(-T から)が処理される前にシンボルが定義され、--defsym-T の後に配置すると、リンカースクリプトが処理された後にシンボルが定義されます。この違いは、リンカースクリプト内の --defsym シンボルを使用する式に影響を与え、どの順序が正しいかは、何を達成しようとしているかによって異なります。

^ -demangle[=style] ^ -no-demangle これらのオプションは、エラーメッセージやその他の出力におけるシンボル名のデマンリングを制御します。リンカーにデマンリングするように指示すると、読みやすい形式でシンボル名を表示しようとします。具体的には、オブジェクトファイル形式で使用されている先頭のアンダースコアを削除し、C++の難読化されたシンボル名をユーザーが読める名前に変換します。異なるコンパイラは異なる難読化スタイルを使用します。オプションのデマンリングスタイル引数を使用して、コンパイラに適したデマンリングスタイルを選択できます。リンカーは、デフォルトでデマンリングを実行します。ただし、環境変数 COLLECT_NO_DEMANGLE が設定されている場合は、この動作が変更されます。これらのオプションを使用して、デフォルトの動作をオーバーライドできます。

^ Ifile ^ -dynamic-linker=file 動的リンカーの名前を設定します。これは、動的にリンクされたELF実行可能ファイルを生成する場合にのみ意味を持ちます。デフォルトの動的リンカーは通常は適切です。特別な理由がない限り、このオプションを使用しないでください。

^ -no-dynamic-linker 実行可能ファイルを生成する際に、ロード時に使用する動的リンカーの要求を省略します。これは、動的リロケーションを含むELF実行可能ファイルにのみ意味があり、通常は、これらのリロケーションを処理できるエントリーポイントコードが必要です。

^ -embedded-relocs このオプションは、--emit-relocs オプションと似ていますが、リロケーションはターゲット固有のセクションに格納されます。このオプションは、BFIN、CR16、およびM68Kターゲットでのみサポートされます。

^ -disable-multiple-abs-defs ^ R または --just-symbols で呼び出されたファイル名にシンボルが含まれる複数の定義を許可しません。

^ -fatal-warnings ^ -no-fatal-warnings すべての警告をエラーとして扱います。デフォルトの動作は、--no-fatal-warnings オプションで復元できます。

^ w ^ -no-warnings 警告またはエラーメッセージを表示しないようにします。これにより、--fatal-warnings が有効になっている場合でも、その動作がオーバーライドされます。このオプションは、出力バイナリが正常に動作しないことがわかっているが、それでも作成する必要がある場合に役立ちます。

^ -force-exe-suffix 出力ファイルに .exe サフィックスが確実に付くようにします。

正常にビルドされ、完全にリンクされた出力ファイルに .exe または .dll のサフィックスが付いていない場合、このオプションはリンカーに、同じ名前で .exe サフィックスが付いたファイルにコピーするように強制します。このオプションは、変更されていないUnix makefileをMicrosoft Windowsホストで使用する場合に役立ちます。なぜなら、Windowsの一部のバージョンでは、.exe サフィックスが付いていないイメージは実行されないからです。


--gc-sections
--no-gc-sections

未使用の入力セクションのガベージコレクションを有効にします。このオプションをサポートしていないターゲットでは無視されます。デフォルトの動作(このガベージコレクションを実行しない)は、コマンドラインで --no-gc-sections を指定することで復元できます。COFF および PE 形式のターゲットに対するガベージコレクションはサポートされていますが、実装は現在、実験的と見なされています。

`--gc-sections` は、シンボルとリロケーションを調べて、使用されている入力セクションを決定します。エントリシンボルを含むセクションと、コマンドラインで未定義のシンボルを含むセクションは保持されます。また、動的オブジェクトによって参照されるシンボルを含むセクションも保持されます。共有ライブラリをビルドする場合、リンカーは、すべての可視シンボルが参照されていると想定する必要があります。この最初のセクションセットを決定すると、リンカーは、それらのリロケーションによって参照されるセクションを再帰的に使用済みとしてマークします。`--entry`、`--undefined`、および `--gc-keep-exported` を参照してください。

このオプションは、部分リンク(-r オプションで有効)を実行するときに設定できます。この場合、保持されるシンボルのルートは、--entry--undefined、または --gc-keep-exported のいずれかのオプション、またはリンカースクリプトの ENTRY コマンドによって明示的に指定する必要があります。

GNU拡張として、SHF_GNU_RETAIN フラグが設定された ELF 入力セクションは、ガベージコレクションの対象外になります。

--print-gc-sections
--no-print-gc-sections

ガベージコレクションによって削除されたすべてのセクションをリストします。リストは stderr に出力されます。このオプションは、--gc-sections オプションによってガベージコレクションが有効になっている場合にのみ有効です。デフォルトの動作(削除されたセクションをリストしない)は、コマンドラインで --no-print-gc-sections を指定することで復元できます。

--gc-keep-exported

^ -gc-sections が有効になっている場合、このオプションは、デフォルトまたは保護された可視性を持つグローバルシンボルを含む、使用されていない入力セクションのガベージコレクションを防止します。このオプションは、参照されていないセクションが、含まれるシンボルの外部可視性に関係なく、ガベージコレクションされる実行可能ファイルで使用することを目的としています。このオプションは、共有オブジェクトをリンクするときには効果がありません。これは、デフォルトの動作であるためです。このオプションは、ELF 形式のターゲットでのみサポートされます。

--print-output-format

デフォルトの出力形式の名前を出力します(他のコマンドラインオプションの影響を受ける場合があります)。これは、リンカースクリプトの OUTPUT_FORMAT コマンドに表示される文字列です。

--print-memory-usage

^ EMORY コマンドで作成されたメモリ領域の、使用サイズ、合計サイズ、および使用サイズを出力します。これは、組み込みターゲットで、利用可能なメモリの量をすばやく確認するのに役立ちます。出力形式は、1つのヘッダーと、1つの領域あたり1行です。これは、人間が読めるだけでなく、ツールによって簡単に解析できます。出力例を次に示します。


メモリ領域  使用サイズ 領域サイズ 使用率 ROM:  256 KB  1 MB  25.00% RAM:  32 B  2 GB  0.00%

注:リンカ自体のメモリ使用量を知りたい場合は、--stats オプションを使用してください。

--help

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

--target-help

ターゲット固有のすべてのオプションの概要を標準出力に出力して終了します。

-Map=mapfile

指定されたファイル mapfile にリンクマップを出力します。上記の説明を参照してください。mapfile が単に文字 "-" の場合、マップは標準出力に出力されます。

mapfile にディレクトリを指定すると、リンクマップはそのディレクトリ内のファイルとして書き込まれます。通常、ディレクトリ内のファイル名は、出力ファイルのベース名に ".map" が追加されたものとして計算されます。ただし、特殊文字 "%" が使用されている場合、これは出力ファイルの完全パスに置き換えられます。さらに、"%" の後に文字がある場合、".map" はもはや追加されません。

-o foo.exe -Map=bar  [./bar を作成]
-o ../dir/foo.exe -Map=bar  [./bar を作成]
-o foo.exe -Map=../dir  [../dir/foo.exe.map を作成]
-o ../dir2/foo.exe -Map=../dir  [../dir/foo.exe.map を作成]
-o foo.exe -Map=%  [./foo.exe.map を作成]
-o ../dir/foo.exe -Map=%  [../dir/foo.exe.map を作成]
-o foo.exe -Map=%.bar  [./foo.exe.bar を作成]
-o ../dir/foo.exe -Map=%.bar  [../dir/foo.exe.bar を作成]
-o ../dir2/foo.exe -Map=../dir/%  [../dir/../dir2/foo.exe.map を作成]
-o ../dir2/foo.exe -Map=../dir/%.bar  [../dir/../dir2/foo.exe.bar を作成]

複数の "%" 文字を指定することはエラーです。

マップファイルがすでに存在する場合、この操作によって上書きされます。

--no-keep-memory

ld は通常、入力ファイルのシンボルテーブルをメモリにキャッシュすることで、速度を優先してメモリ使用量を最適化します。このオプションは、必要に応じてシンボルテーブルを再読み込みすることで、メモリ使用量を優先するように ld に指示します。これは、ld が大規模な実行ファイルをリンクする際にメモリ容量を超えた場合に必要になる場合があります。

--no-undefined
-z defs

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

このオプションの効果は、"-z undefs" を使用して元に戻すことができます。

--allow-multiple-definition
-z muldefs

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

--allow-shlib-undefined
--no-allow-shlib-undefined

共有ライブラリ内の未定義シンボルを許可または禁止します。このスイッチは、--no-undefined と似ていますが、未定義シンボルが通常のオブジェクトファイルではなく、共有ライブラリにある場合にのみ動作を決定します。通常のオブジェクトファイル内の未定義シンボルの処理には影響しません。


デフォルトの動作では、リンカーが実行可能ファイルを生成するために使用されている場合、共有ライブラリで参照されている未定義のシンボルに対してエラーが報告されますが、リンカーが共有ライブラリを生成するために使用されている場合は、エラーは許可されます。

リンク時に指定された共有ライブラリが、ロード時に利用可能なものと異なる場合があるため、シンボルはロード時に解決できる可能性があります。

BeOSやHPPAなど、一部のオペレーティングシステムでは、共有ライブラリ内の未定義シンボルが通常です。

たとえば、BeOSカーネルは、共有ライブラリをロード時にパッチ処理して、現在のアーキテクチャに最適な関数を選択します。これは、適切なmemset関数を動的に選択するために使用されます。

--error-handling-script=スクリプト名

このオプションが指定された場合、リンカーはエラーが発生するたびにスクリプト名で指定されたスクリプトを呼び出します。現在、サポートされているエラーの種類は、シンボルの欠落とライブラリの欠落の2つだけです。スクリプトには、キーワード「undefined-symbol」または「missing-lib」と、未定義シンボルの名前または欠落したライブラリの名前の2つの引数が渡されます。スクリプトは、シンボルまたはライブラリを見つけることができる場所について、ユーザーに提案を提供することを目的としています。スクリプトが完了すると、通常のリンカーエラーメッセージが表示されます。

このオプションの可用性は、構成時のスイッチによって制御されるため、特定の実装では存在しない場合があります。

--no-undefined-version

通常、シンボルに未定義のバージョンがある場合、リンカーはそれを無視します。このオプションでは、未定義のバージョンを持つシンボルが許可されなくなり、代わりに致命的なエラーが発生します。

--default-symver

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

--default-imported-symver

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

--no-warn-mismatch

通常、ldは、入力ファイルが何らかの理由で互換性がない場合(たとえば、異なるプロセッサまたは異なるエンディアン用にコンパイルされた場合)にエラーを表示します。このオプションは、ldがそのような潜在的なエラーをサイレントに許可するように指示します。このオプションは、特別な対策を講じてリンカーエラーが不適切であることを確認した場合にのみ、注意して使用する必要があります。

--no-warn-search-mismatch

通常、ldは、ライブラリの検索中に互換性のないライブラリが見つかった場合に警告を表示します。このオプションは、警告を抑制します。

--no-whole-archive

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


--noinhibit-exec

実行可能ファイルがまだ使用可能な場合でも、それを保持します。通常、リンカーはリンク処理中にエラーが発生した場合、エラーが発生した時点で出力ファイルを作成せずに終了します。

-nostdlib

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

--oformat=output-format

ldは、複数の種類のオブジェクトファイルをサポートするように構成できます。ldがこのように構成されている場合は、--oformatオプションを使用して、出力オブジェクトファイルのバイナリ形式を指定できます。ldが代替オブジェクトファイルをサポートするように構成されている場合でも、通常はこれを指定する必要はありません。ldは、各マシンで最も一般的な形式をデフォルトの出力形式として生成するように構成されているはずです。output-formatはテキスト文字列で、BFDライブラリでサポートされている特定の形式の名前です。(objdump -iで利用可能なバイナリ形式を一覧表示できます。)スクリプトコマンド「OUTPUT_FORMAT」も出力形式を指定できますが、このオプションはそれをオーバーライドします。

--out-implib file

リンカーが生成している実行可能ファイル(例:DLLまたはELFプログラム)に対応するインポートライブラリをfileに作成します。このインポートライブラリ(DLLの場合は「*.dll.a」または「*.a」という名前になる必要があります)は、生成された実行可能ファイルに対してクライアントをリンクするために使用できます。これにより、個別のインポートライブラリ作成ステップ(例:DLLの場合は「dlltool」)をスキップできます。このオプションは、i386 PEおよびELFターゲットのリンカーでのみ利用可能です。

-pie
--pic-executable

位置に依存しない実行可能ファイルを作成します。これは現在、ELFプラットフォームでのみサポートされています。位置に依存しない実行可能ファイルは、動的リンカーによってOSが選択した仮想アドレスにリロケーションされます。これは、実行ごとに異なる場合があります。これらはELFファイルヘッダーでET_DYNとしてマークされますが、共有ライブラリとはいくつかの点で異なります。特に、PIEで定義されたシンボルは、共有ライブラリでは可能なように、別のオブジェクトによってオーバーライドすることはデフォルトではできません。

-no-pie

位置に依存する実行可能ファイルを作成します。これはデフォルトです。

-qmagic

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

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

--relax
--no-relax

機械に依存する効果のあるオプションです。このオプションは、いくつかのターゲットでのみサポートされています。

一部のプラットフォームでは、--relaxオプションは、リンカーがプログラムのアドレス解決を行うときに可能になる、ターゲット固有のグローバル最適化を実行します。これには、アドレスモードの緩和、新しい命令の合成、現在の命令の短いバージョンの選択、および定数値の結合が含まれます。

一部のプラットフォームでは、これらのリンク時間のグローバル最適化により、結果として得られる実行可能ファイルのシンボリックデバッグが不可能になる場合があります。これは、松下MN10200およびMN10300プロセッサファミリーの場合であることが知られています。


機能がサポートされているプラットフォームでは、--no-relax オプションを使用すると、その機能を無効にできます。

機能がサポートされていないプラットフォームでは、--relax--no-relax の両方のオプションを受け入れますが、無視されます。

^ -retain-symbols-file=filename ファイル filename にリストされているシンボルのみを保持し、他のすべてのシンボルを破棄します。filename は、各行に 1 つのシンボル名が記述された単純なテキストファイルです。このオプションは、グローバルシンボルテーブルが徐々に蓄積される環境(VxWorksなど)で、実行時のメモリを節約するために特に役立ちます。

^ -retain-symbols-file は、未定義のシンボルまたは再配置に必要なシンボルを破棄しません。

コマンドラインで --retain-symbols-file を指定できるのは 1 回だけです。-s および -S をオーバーライドします。

^ rpath=dir 実行時に共有オブジェクトを検索するために、ディレクトリをランタイムライブラリの検索パスに追加します。これは、共有オブジェクトを持つ ELF 実行可能ファイルをリンクする場合に使用します。すべての -rpath 引数は連結され、ランタイムリンカーに渡され、ランタイムリンカーはそれらを使用して共有オブジェクトを検索します。

^ rpath オプションは、リンクされた共有オブジェクトが必要な共有オブジェクトを明示的に含むリンクの場合にも使用されます。-rpath-link オプションの説明を参照してください。この方法での -rpath の検索は、ネイティブリンカーと --with-sysroot オプションで構成されたクロスリンカーでのみサポートされます。

^ rpath を使用せずに ELF 実行可能ファイルをリンクする場合、定義されていれば、環境変数 LD_RUN_PATH の内容が使用されます。

^ rpath オプションは、SunOS でも使用できます。デフォルトでは、SunOS ではリンカーは、与えられたすべての -L オプションからランタイム検索パスを形成します。-rpath オプションが使用される場合、ランタイム検索パスは -rpath オプションのみを使用して形成され、-L オプションは無視されます。これは、多くの -L オプションを追加する gcc を使用する場合に役立ちます。これらのオプションは、NFS マウントされたファイルシステムにある可能性があります。

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

^ rpath-link=dir ELF または SunOS を使用する場合、1 つの共有ライブラリが別の共有ライブラリを必要とする場合があります。これは、ld -shared リンクが共有ライブラリを 1 つの入力ファイルとして含む場合に発生します。

リンカーが非共有、非再配置可能なリンクでそのような依存関係に遭遇した場合、明示的に含まれていない限り、必要な共有ライブラリを自動的に検索してリンクに含めます。この場合、いくつかのディレクトリが以下に説明するように検索されます。-rpath-link オプションは、検索する最初のディレクトリセットを指定します。 このオプションは、コロンで区切られた名前のリストを提供するか、複数回出現させることによって、一連のディレクトリ名を指定できます。

これらの検索ディレクトリには、トークン $ORIGIN および $LIB が含まれる場合があります。これらは、プログラムまたは共有オブジェクトを含むディレクトリへのフルパス($ORIGIN の場合)または 32 ビットバイナリの場合は lib、64 ビットバイナリの場合は lib64$LIB の場合)に置き換えられます。


これらのトークンの代替形式である ${ORIGIN} および ${LIB} も使用できます。トークン $PLATFORM はサポートされていません。

^ -rpath-link オプションは慎重に使用する必要があります。なぜなら、これは、共有ライブラリにハードコードされた検索パスを上書きする可能性があるからです。そのような場合、実行時リンカーが使用するパスとは異なる検索パスを意図せずに使用してしまう可能性があります。

追加の共有ライブラリが必要な場合、リンカーは、以下に示す順序でディレクトリを検索して、それらを見つけます。ただし、これは、すでに含まれている共有ライブラリの依存関係を満たすために必要な追加のライブラリにのみ適用されることに注意してください。-l コマンドラインオプションで含まれるライブラリについては、この検索は行われません。-l ライブラリの検索は、-L オプションで指定されたディレクトリでのみ行われます。

`-rpath-link` オプションで指定されたディレクトリ。
`-rpath` オプションで指定されたディレクトリ。`-rpath` と `-rpath-link` の違いは、`-rpath` オプションで指定されたディレクトリは実行ファイルに含められ、実行時に使用されるのに対し、`-rpath-link` オプションはリンク時にのみ有効であることです。このように `-rpath` を検索することは、ネイティブリンカーと `--with-sysroot` オプションで構成されたクロスリンカーでのみサポートされます。
ELF システムでは、ネイティブリンカーの場合、`-rpath` および `-rpath-link` オプションが使用されていない場合、環境変数 `LD_RUN_PATH` の内容を検索します。
SunOS では、`-rpath` オプションが使用されていない場合、`-L` オプションを使用して指定されたディレクトリを検索します。
ネイティブリンカーの場合、環境変数 `LD_LIBRARY_PATH` の内容を検索します。
ネイティブ ELF リンカーの場合、共有ライブラリの `DT_RUNPATH` または `DT_RPATH` に含まれるディレクトリが、その共有ライブラリに必要な共有ライブラリの検索に使用されます。`DT_RPATH` エントリは、`DT_RUNPATH` エントリが存在する場合は無視されます。
Linux システムのリンカーの場合、ファイル `/etc/ld.so.conf` が存在する場合は、そのファイルに含まれるディレクトリのリストを検索します。注: このファイルのパスには、`sysroot` 値が定義されている場合はその値が、またリンカーが `--prefix=<path>` オプションで構成されている場合は、その `prefix` 文字列が先頭に追加されます。
ネイティブリンカーが FreeBSD システムで実行されている場合、`elf-hints.h` ヘッダーファイルで定義されている `_PATH_ELF_HINTS` マクロによって指定されたディレクトリを検索します。
コマンドラインで指定されたリンカースクリプトに、`-T` (ただし `-dT` ではない) で指定されたスクリプトを含む、`SEARCH_DIR` コマンドが含まれている場合、それらのディレクトリを検索します。
デフォルトのディレクトリ、通常は `/lib` および `/usr/lib`。
プラグイン `LDPT_SET_EXTRA_LIBRARY_PATH` で指定されたディレクトリ。
デフォルトのリンカースクリプトに `SEARCH_DIR` コマンドが含まれている場合、それらのディレクトリを検索します。

ただし、Linux ベースのシステムでは、追加の注意点があります。--as-needed オプションがアクティブであり、通常は検索を満たす共有ライブラリが見つかり、そのライブラリに libc.soDT_NEEDED タグがなく、セット内の後続の共有ライブラリにも libc.soDT_NEEDED タグがある場合、この 2 番目のライブラリが選択され、最初のライブラリの代わりに選択されます。


必要な共有ライブラリが見つからない場合、リンカーは警告を発し、リンク処理を続行します。

--section-ordering-file=script

このオプションは、現在のリンカースクリプトに追加のマッピングを使用して、入力セクションを出力セクションにマップするために使用されます。このファイルは、通常のリンカースクリプトで使用される「SECTIONS」の構文を使用する必要がありますが、入力セクションを出力セクションに配置すること以外の操作は行わないようにする必要があります。@pxref{SECTIONS}

セクション順序付けスクリプトに対する2番目の制約は、参照できるのは、現在使用中のリンカースクリプト(デフォルトのリンカースクリプトまたはコマンドラインで指定されたスクリプト)によってすでに定義されている出力セクションのみであることです。ただし、セクション順序付けスクリプトの利点は、入力セクションが出力セクションの先頭にマップされるため、出力セクション内のセクションの順序を保証できることです。たとえば、デフォルトのリンカースクリプトが次のようになっているとします。

SECTIONS {
.text : { *(.text.hot) ; *(.text .text.*) }
.data : { *(.data.big) ; *(.data .data.*) }
}

そして、次のようなセクション順序付けファイルを使用すると、

.text : { *(.text.first) ; *(.text.z*) }
.data : { foo.o(.data.first) ; *(.data.small) }

これは、次のようなリンカースクリプトと同等になります。

SECTIONS {
.text : { *(.text.first) ; *(.text.z*) ; *(.text.hot) ; *(.text .text.*) }
.data : { foo.o(.data.first) ; *(.data.small) ; *(.data.big) ; *(.data .data.*) }
}

セクション順序付けファイルの利点は、ユーザーにとって重要なセクションを、他のセクション、メモリ領域、またはその他の要素を気にする必要なく順序付けできることです。

-shared
-Bshareable

共有ライブラリを作成します。これは、現在、ELF、XCOFF、およびSunOSプラットフォームでのみサポートされています。SunOSでは、リンカーは-eオプションが使用されず、リンクに未定義のシンボルが含まれている場合、自動的に共有ライブラリを作成します。

--sort-common
--sort-common=ascending
--sort-common=descending

このオプションは、ldに共通シンボルを適切な出力セクションに配置する際に、16バイト以上の、8バイト、4バイト、2バイト、1バイトの順序で、アラインメントによってソートするように指示します。これは、アラインメント制約によるシンボル間のギャップを防ぐためです。ソート順が指定されていない場合は、降順が仮定されます。

--sort-section=name

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


--sort-section=alignment

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

--spare-dynamic-tags=count

このオプションは、ELF共有オブジェクトの.dynamicセクションに残す空のスロットの数を指定します。空のスロットは、プリリンカなどの後処理ツールによって必要となる場合があります。デフォルトは5です。

--split-by-file[=size]

--split-by-relocと似ていますが、入力ファイルごとに新しい出力セクションを作成し、サイズが指定された値に達した場合に分割します。sizeが指定されていない場合は、デフォルトで1になります。

--split-by-reloc[=count]

出力ファイルの追加のセクションを作成し、出力ファイル内の単一のセクションにcount以上のリロケーションが含まれないようにします。これは、COFFオブジェクトファイル形式を使用して、特定のリアルタイムカーネルにダウンロードするために巨大なリロケーション可能なファイルを生成する場合に役立ちます。COFFは単一のセクションで65535を超えるリロケーションを表すことができないためです。ただし、このオプションは、任意のセクションをサポートしないオブジェクトファイル形式では機能しません。リンカは個々の入力セクションを再配布するために分割しないため、単一の入力セクションにcountを超えるリロケーションが含まれている場合、1つの出力セクションにはその数のリロケーションが含まれます。countのデフォルト値は32768です。

--stats[=filename]

リンカの動作に関する統計(実行時間やメモリ使用量など)を計算して表示します。

オプションのファイル名引数が指定されていない場合、基本的な情報のみが報告され、標準エラー出力ストリームに送信されます。ファイル名引数が指定された場合、拡張された情報が指定されたファイルに書き込まれます。ファイル名が単なるシンボルに設定されている場合、拡張された情報は標準出力ストリームに送信されます。ファイル名が+で始まる場合、ファイルは上書きモードではなく追加モードで開かれます。

-Mapオプションが有効になっている場合、情報はマップファイルにも記録されます。注意:--statsオプションと-Mapオプションの両方にファイル名引数が指定され、それらが一致する場合、情報は2回書き込まれるのではなく1回だけ書き込まれます。

「LD_STATS」環境変数が定義されている場合、これは--statsオプションと同様に動作します。変数の値が文字列の場合、これは情報を記録するファイルの名前として使用されます。それ以外の場合、情報は標準出力ストリームに送信されます。環境変数を使用すると、リンカのコマンドラインを変更せずに統計を記録できます。注意:環境変数と--statsオプションの両方が使用されている場合、--statsオプションが優先されます。

報告される拡張情報には、CPU時間と、getrusage()システムライブラリ呼び出しが利用可能な場合、メモリの使用量が含まれます。この情報は、リンキングプロセスの個々の部分と呼ばれるフェーズごとに報告されます。さらに、情報は「ALL」と呼ばれる特別なフェーズにも報告され、これはリンキングプロセスの全体をカバーします。個々のフェーズは互いに含まれるか、重複する可能性があるため、リンカによって使用される全体的なリソースは、個々のフェーズによって使用されるリソースの合計であると想定しないでください。


さらに、詳細な情報が報告される場合、リンカーのバージョン、コマンドライン引数、およびリンカーの開始時間も含まれます。これにより、ビルドシステムによって複数のリンクが呼び出され、報告された統計を生成した正確な引数を特定することが容易になります。

拡張出力は次のようになります。

Stats: linker version: (GNU Binutils) 2.44.50.20250401
Stats: linker started: Wed Apr 2 09:36:41 2025
Stats: args: ld -z norelro -z nomemory-seal -z no-separate-code -o a.out [...]

Stats: phase               cpu time    memory      user time    system time
Stats: name                (マイクロ秒)   (KiB)      (秒)      (秒)
Stats: ALL                   390082    217740              0              0
Stats: ctf processing            12         0              0              0
Stats: string merge            1324         0              0              0
Stats: parsing                  349       288              0              0
Stats: plugins                    1         0              0              0
Stats: processing files      259616    214524              0              0
Stats: write                 116493         0              0              0

--no-stats
`--stats` コマンドラインオプションまたは `LD_STATS` 環境変数によって有効になっている場合、使用状況統計の報告を無効にします。

--sysroot=directory
`--with-sysroot` を使用して構成されたリンカーのみがサポートする、sysroot の場所としてディレクトリを使用し、構成時のデフォルトを上書きします。

--task-link
これは、COFF/PE ベースのターゲットで使用され、すべてのグローバルシンボルが静的シンボルに変換されたタスクリンクされたオブジェクトファイルを作成します。

--traditional-format
一部のターゲットでは、`ld` の出力は、既存のリンカーの出力とはいくつかの点で異なります。このスイッチは、`ld` に従来の形式を使用するように要求します。

たとえば、SunOS では、`ld` はシンボル文字列テーブル内の重複するエントリを結合します。これにより、完全なデバッグ情報を含む出力ファイルのサイズを 30% 以上削減できます。残念ながら、SunOS の `dbx` プログラムは、結果として生成されたプログラムを読み取ることができません (ただし、`gdb` には問題はありません)。`--traditional-format` スイッチは、`ld` に重複するエントリを結合しないように指示します。

--section-start=sectionname=org
出力ファイル内のセクションを、`org` で指定された絶対アドレスに配置します。コマンドラインで必要な回数だけ、このオプションを使用できます。`org` は、16 進数の整数である必要があります。他のリンカーとの互換性のために、通常 16 進数に関連付けられている先頭の `0x` を省略できます。注: `sectionname`、等号 (`=`)、および `org` の間に空白を入れないでください。

--image-base=org

ELFを使用する場合、-Ttext-segmentと同じで、このオプションもELF実行ファイルのベースアドレスを設定します。

PEを使用する場合、プログラムまたはDLLのベースアドレスとして値を設定します。これは、プログラムまたはDLLがロードされるときに使用される最も低いメモリ位置です。DLLのリロケーションの必要性を減らし、パフォーマンスを向上させるために、各DLLは一意のベースアドレスを持ち、他のDLLとオーバーラップしないようにする必要があります。デフォルトは、実行可能ファイルの場合は0x400000、DLLの場合は0x10000000です。

-Tbss=org
-Tdata=org
-Ttext=org

-section-startと同じで、セクション名は".bss"、".data"、または".text"です。

-Ttext-segment=org

ELF実行ファイルを作成する場合、これは最初のセグメントの最初のバイトのアドレスを設定します。-pieオプションと-Ttext-segment=orgを組み合わせて使用​​すると、出力実行ファイルはET_EXECとしてマークされ、テキストセグメントの最初のバイトのアドレスが実行時にorgになることが保証されます。

-Trodata-segment=org

読み取り専用データが実行可能テキストとは別のセグメントにあるターゲットのELF実行ファイルまたは共有オブジェクトを作成する場合、これは読み取り専用データセグメントの最初のバイトのアドレスを設定します。

-Tldata-segment=org

x86-64ミディアムメモリモデルのELF実行ファイルまたは共有オブジェクトを作成する場合、これはldataセグメントの最初のバイトのアドレスを設定します。

--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[=NUMBER]

ldのバージョン番号を表示し、リンカーがサポートするリンカエミュレーションをリストします。開くことができるファイルと開くことができないファイルを表示します。リンカーが使用しているリンカースクリプトを表示します。オプションのNUMBER引数が1より大きい場合、プラグインシンボルのステータスも表示されます。

--version-script=version-scriptfile

リンカーにバージョンスクリプトの名前を指定します。これは通常、共有ライブラリを作成するときに、ライブラリのバージョン階層に関する追加情報を指定するために使用されます。このオプションは、共有ライブラリを完全にサポートするELFプラットフォームでのみ完全にサポートされます。VERSIONを参照してください。PEプラットフォームでも部分的にサポートされており、バージョンスクリプトを使用して、自動エクスポートモードでシンボルの表示をフィルタリングできます。バージョンスクリプトでローカルとマークされたシンボルはエクスポートされません。


--warn-common

共通シンボルが別の共通シンボルまたはシンボル定義と組み合わされた場合に警告を表示します。 Unixリンカーは、このような多少不正確な方法を許可していますが、他のオペレーティングシステムのリンカーは許可しません。 このオプションを使用すると、グローバルシンボルを組み合わせることで発生する可能性のある問題を特定できます。 残念ながら、一部のCライブラリはこの方法を使用しているため、ライブラリのシンボルについても、プログラムのシンボルについても警告が表示される場合があります。

グローバルシンボルの種類は次の3つです。以下にCの例を示します。

int i = 1;

定義。出力ファイルの初期化されたデータセクションに配置されます。

extern int i;

未定義の参照。スペースは割り当てられません。変数に対しては、定義または共通シンボルのいずれかが必要です。

int i;

共通シンボル。変数の共通シンボルが1つだけ(または複数ある)場合、出力ファイルの初期化されていないデータ領域に配置されます。 リンカーは、同じ変数の複数の共通シンボルを1つのシンボルにマージします。それらのサイズが異なる場合、最も大きいサイズが選択されます。 リンカーは、同じ変数の定義が存在する場合、共通シンボルを宣言に変換します。

--warn-commonオプションは、5種類の警告を生成できます。各警告は、2行のペアで構成されます。 最初の行は、現在遭遇したシンボルについて説明し、2行目は、同じ名前で以前に遭遇したシンボルについて説明します。 2つのシンボルのうち、少なくとも1つは共通シンボルになります。

共通シンボルを、同じシンボルの定義がすでに存在するため、参照に変換します。

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

共通シンボルを、後続の定義がシンボルで遭遇したため、参照に変換します。 これは前のケースと同じですが、シンボルが異なる順序で遭遇します。

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

共通シンボルを、以前の同じサイズの共通シンボルとマージします。

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

共通シンボルを、以前のより大きな共通シンボルとマージします。

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

共通シンボルを、以前のより小さな共通シンボルとマージします。これは前のケースと同じですが、シンボルが異なる順序で遭遇します。


<file>(<section>): warning: `<symbol>' の共通部分が重複しています
より小さい共通部分を上書きします
<file>(<section>): warning: ここに小さい共通部分があります

--warn-constructors
グローバルコンストラクタが使用されている場合に警告を表示します。これは、一部のオブジェクトファイル形式でのみ有効です。
COFFやELFなどの形式では、リンカはグローバルコンストラクタの使用を検出できません。

--warn-execstack
--warn-execstack-objects
--no-warn-execstack
ELFプラットフォームでは、リンカが実行可能スタックを含む出力ファイルを作成するように求められた場合、警告メッセージを生成する場合があります。
3つの可能な状態があります。

     警告を生成しません。

     `-z execstack` コマンドラインオプションを使用して実行可能スタックが要求された場合でも、常に警告を生成します。

     オブジェクトファイルが実行可能スタックを要求している場合にのみ警告を生成し、`-z execstack` オプションが使用されている場合は警告を生成しません。

デフォルトの状態は、リンカがビルドされたときの構成によって異なります。
`--no-warn-execstack` オプションは、常にリンカを警告なしの状態にします。
`--warn-execstack` オプションは、リンカを常に警告を生成する状態にします。
`--warn-execstack-objects` オプションは、リンカをオブジェクトファイルのみに対して警告を生成する状態にします。

注:ELF形式の入力ファイルは、`.note.GNU-stack` セクションを持ち、そのセクションフラグで実行可能ビットが設定されていることで、実行可能スタックが必要であることを指定できます。
`.note.GNU-stack` セクションを持ち、実行可能ビットが設定されていないことで、実行可能スタックが不要であることを指定できます。
入力ファイルに`.note.GNU-stack` セクションがない場合、デフォルトの動作はターゲットによって異なります。
一部のターゲットでは、そのようなセクションの不在は、実行可能スタックが必要であることを意味します。これは、手動で作成されたアセンブラファイルで問題になることがよくあります。

--error-execstack
--no-error-execstack
リンカが実行可能スタックに関する警告メッセージを生成する場合、`--error-execstack` オプションはその警告をエラーに変更します。
このオプションは、リンカのexecstack警告生成状態を変更しません。
`--warn-execstack` または `--warn-execstack-objects` を使用して、特定の警告状態を設定します。

`--no-error-execstack` オプションは、警告メッセージを生成するデフォルトの動作を復元します。

--warn-multiple-gp
出力ファイルで複数のグローバルポインタ値が必要な場合に警告を表示します。
これは、Alphaなどの特定のプロセッサでのみ意味があります。
具体的には、一部のプロセッサは、大きな値を持つ定数を特別なセクションに配置します。
特別なレジスタ(グローバルポインタ)は、このセクションの中央を指し、定数をベースレジスタ相対アドレスモードで効率的にロードできるようにします。
ベースレジスタ相対アドレスモードのオフセットは固定されており、比較的小さいため(例:16ビット)、定数プールの最大サイズが制限されます。
したがって、大規模なプログラムでは、すべての可能な定数にアドレス指定できるように、複数のグローバルポインタ値を使用する必要がある場合があります。
このオプションは、この場合に警告を発行します。

--warn-once

未定義のシンボルごとに、1回だけ警告を表示します。モジュールごとに警告を表示するのではなく、未定義のシンボルごとに警告を表示します。

--warn-rwx-segments
--no-warn-rwx-segments

リンカーが読み取り、書き込み、および実行のすべての権限フラグが設定された、ロード可能なゼロ以外のサイズのセグメントを作成した場合に警告します。このようなセグメントは潜在的なセキュリティ上の脆弱性を示します。さらに、読み取りおよび/または書き込みフラグが設定されているかどうかに関わらず、実行権限フラグが設定されたスレッドローカルストレージセグメントが作成された場合にも警告が生成されます。

これらの警告はデフォルトで有効になっています。 --no-warn-rwx-segmentsオプションで無効にしたり、--warn-rwx-segmentsオプションで再度有効にしたりできます。

--error-rwx-segments
--no-error-rwx-segments

リンカーが実行可能、書き込み可能なセグメント、または実行可能なTLSセグメントに関する警告メッセージを生成する場合、--error-rwx-segmentsオプションを使用すると、この警告がエラーに変換されます。 --no-error-rwx-segmentsオプションを使用すると、警告メッセージのみを生成するデフォルトの動作が復元されます。

注意:--error-rwx-segmentsオプション自体では、これらのセグメントに関する警告は有効になりません。これらの警告は、リンカーがそのように構成されている場合、または--warn-rwx-segmentsコマンドラインオプションを使用して、デフォルトで有効になります。

--warn-section-align

出力セクションのアドレスがアライメントのために変更された場合に警告します。通常、アライメントは入力セクションによって設定されます。アドレスが明示的に指定されていない場合、つまり、「SECTIONS」コマンドが出力セクションの開始アドレスを指定していない場合にのみ、アドレスが変更されます。

--warn-textrel

リンカーが位置に依存する実行可能ファイルまたは共有オブジェクトにDT_TEXTRELを追加した場合に警告します。

--warn-alternate-em

オブジェクトに別のELFマシンコードがある場合に警告します。

--warn-unresolved-symbols

リンカーが未解決のシンボルを報告する場合(--unresolved-symbolsオプションを参照)、通常はエラーを生成します。このオプションを使用すると、エラーではなく警告を生成します。

--error-unresolved-symbols

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

--whole-archive

コマンドラインで--whole-archiveオプションの後に続く各アーカイブについて、必要なオブジェクトファイルを検索するのではなく、アーカイブ内のすべてのオブジェクトファイルをリンクに含めます。通常、これはアーカイブファイルを共有ライブラリに変換するために使用され、すべてのオブジェクトを結果の共有ライブラリに含めるように強制します。このオプションは複数回使用できます。

gccでこのオプションを使用する場合の2つの注意点:最初に、gccはこのオプションを知らないため、-Wl,-whole-archiveを使用する必要があります。2番目に、-Wl,-no-whole-archiveをアーカイブのリストの後に使用することを忘れないでください。これは、gccが独自のアーカイブのリストをリンクに追加するため、そのアーカイブにこのフラグが影響を与えないようにするためです。


--wrap=symbol
シンボルのためのラッパー関数を使用します。シンボルへの未定義の参照はすべて、"__wrap_symbol" に解決されます。 "__real_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" にラップする前に、呼び出しを解決してしまう可能性があります。

リンカーによって未定義の参照のみが置き換えられます。したがって、翻訳ユニット内のシンボルへの参照は "__wrap_symbol" に解決されません。次の例では、 "g" 内の "f" への呼び出しは "__wrap_f" に解決されません。

int
f (void)
{
return 123;
}

int
g (void)
{
return f();
}

--eh-frame-hdr
--no-eh-frame-hdr
".eh\_frame\_hdr" セクションと ELF "PT\_GNU\_EH\_FRAME" セグメントヘッダーの作成を要求 (--eh-frame-hdr) するか、抑制 (--no-eh-frame-hdr) します。

--no-ld-generated-unwind-info
リンカーが生成する PLT などのコードセクションの ".eh\_frame" アンワインド情報を要求します。このオプションは、リンカーが生成するアンワインド情報がサポートされている場合はデフォルトでオンになっています。このオプションは、リンカーが生成する PLT などのコードセクションの ".sframe" スタックトレース情報の生成も制御します。

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

--hash-size=number
リンカーのハッシュテーブルのデフォルトサイズを、number に近い素数に設定します。この値を大きくすると、リンカーがタスクを実行するのにかかる時間が短縮されますが、リンカーのメモリ要件が増加します。同様に、この値を小さくすると、メモリ要件が削減されますが、速度が低下します。デフォルト値は、通常は 4051、`--reduce-memory-overheads` コマンドラインオプションを使用する場合は 1021 です。

--hash-style=スタイル

リンカーのハッシュテーブルのタイプを設定します。スタイルは、従来のELF ".hash" セクションを表す "sysv"、新しいスタイルのGNU ".gnu.hash" セクションを表す "gnu"、または、従来のELF ".hash" と新しいスタイルのGNU ".gnu.hash" の両方のハッシュテーブルを表す "both" のいずれかになります。デフォルトは、リンカーの構成方法によって異なりますが、ほとんどのLinuxベースのシステムでは "both" になります。

--compress-debug-sections=none
--compress-debug-sections=zlib
--compress-debug-sections=zlib-gnu
--compress-debug-sections=zlib-gabi
--compress-debug-sections=zstd

ELFプラットフォームでは、これらのオプションは、zlibを使用してDWARFデバッグセクションを圧縮する方法を制御します。

--compress-debug-sections=none は、DWARFデバッグセクションを圧縮しません。
--compress-debug-sections=zlib-gnu は、DWARFデバッグセクションを圧縮し、セクション名を ".debug" ではなく ".zdebug" で始まるように変更します。--compress-debug-sections=zlib-gabi もDWARFデバッグセクションを圧縮しますが、セクション名を変更する代わりに、セクションヘッダーに SHF_COMPRESSED フラグを設定します。

--compress-debug-sections=zlib オプションは、--compress-debug-sections=zlib-gabi と同じ意味です。

--compress-debug-sections=zstd は、zstdを使用してDWARFデバッグセクションを圧縮します。

このオプションは、入力デバッグセクションの圧縮を上書きするため、たとえば、--compress-debug-sections=none を使用してバイナリをリンクすると、入力ファイル内の圧縮されたデバッグセクションは、出力バイナリにコピーされる前に非圧縮されます。

デフォルトの圧縮動作は、ターゲットとツールチェーンの構築に使用される構成オプションによって異なります。デフォルトは、リンカーの --help オプションの出力から確認できます。

--reduce-memory-overheads

このオプションは、ld実行時のメモリ要件を削減しますが、リンク速度が低下します。これは、リンクマップファイルの生成に古いO(n^2)アルゴリズムを選択するために導入されました。新しいO(n)アルゴリズムは、約40%多くのメモリをシンボルストレージに使用します。

このスイッチのもう1つの効果は、デフォルトのハッシュテーブルサイズを1021に設定することです。これにより、メモリを節約できますが、リンカーの実行時間が長くなります。ただし、--hash-sizeスイッチが使用されている場合は、この処理は行われません。

--reduce-memory-overheadsスイッチは、リンカーの将来のバージョンで他のトレードオフを有効化するためにも使用できます。

--max-cache-size=サイズ

ldは通常、入力ファイルの再配置情報とシンボルテーブルを、制限なしのサイズでメモリにキャッシュします。このオプションは、最大キャッシュサイズをサイズに設定します。--no-keep-memoryコマンドラインオプションが使用されている場合、リンカーは最大キャッシュサイズが0に設定されているかのように動作します。つまり、何も保持されません。

--build-id
--build-id=スタイル

".note.gnu.build-id" ELFノートセクションまたは".buildid" COFFセクションの作成を要求します。ノートの内容は、このリンクされたファイルを一意に識別するビットです。スタイルは、128ビットのランダムビットを使用する "uuid"、160ビットのSHA1ハッシュを使用する "sha1"、128ビットのMD5ハッシュを使用する "md5"、または、出力内容の規範的な部分に128ビットのXXHASHを使用する "xx"、または、選択されたビット文字列を、偶数の16進数の数字として指定する "0xhexstring"("-"および":"文字は数字のペアの間に無視されます)になります。スタイルが省略された場合、"sha1" が使用されます。


「md5」、「sha1」、および「xx」スタイルは、同一の出力ファイルでは常に同じ識別子を生成しますが、それ以外のすべてのファイルではほぼ確実に一意になります。 これは、ファイルのコンテンツのチェックサムとして比較することを目的としていません。リンクされたファイルは後で他のツールによって変更される可能性がありますが、元のリンクされたファイルを識別するビルド ID ビット文字列は変更されません。

「none」をスタイルとして渡すと、コマンドラインの以前のすべての --build-id オプションの設定が無効になります。

`--package-metadata=JSON`
`.note.package` ELF ノートセクションの作成を要求します。ノートの内容は、パッケージメタデータ仕様に従って JSON 形式になります。詳細については、(https://systemd.io/ELF_PACKAGE_METADATA/) を参照してください。JSON 引数は、パーセントエンコーディングと、次の形式のエンコーディング %[string] (ここで、string は HTML の名前付き文字参照にあります) をサポートします。%[comma] は、, になり、%[lbrace] は、{ になり、%[quot] は、" になり、%[rbrace] は、} になり、%[space] は、スペース文字になります。JSON 引数が欠落しているか空の場合、以前に `--package-metadata` オプションで有効になっていたメタデータノートの作成が無効になります。リンカーが libjansson でビルドされている場合、JSON 文字列は検証されます。

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

すべてのターゲットで共通のオプションに加えて、i386 PE リンカーは、i386 PE ターゲットに固有の追加のコマンドラインオプションをサポートします。値を取るオプションは、値とスペースまたは等号で区切ることができます。

`--add-stdcall-alias`

指定された場合、@nn のサフィックスを持つシンボルは、そのままエクスポートされ、サフィックスが削除された状態でエクスポートされます。[このオプションは、i386 PE ターゲットのリンカーに固有です]

`--base-file file`

DLL を生成するために必要なすべてのリロケーションの基本アドレスを保存するために使用するファイルの名前として、file を使用します。[これは i386 PE に固有のオプションです]

`--dll`

通常の実行可能ファイルではなく、DLL を作成します。-shared を使用するか、指定された .def ファイルで LIBRARY を指定することもできます。[このオプションは、i386 PE ターゲットのリンカーに固有です]


--enable-long-section-names
--disable-long-section-names

PE形式のCOFFオブジェクト形式は、通常COFFの制限である8文字を超えるセクション名を使用できるようにする拡張機能を追加します。デフォルトでは、これらの名前はオブジェクトファイルでのみ許可され、完全にリンクされた実行可能イメージには、長い名前をサポートするために必要なCOFF文字列テーブルが含まれていません。GNU拡張として、これらのオプションを使用することで、実行可能イメージでの使用を許可したり、(おそらく無意味に!)オブジェクトファイルでの使用を禁止したりすることもできます。これらの長いセクション名を使用して生成された実行可能イメージは、文字列テーブルを含んでいるため、わずかに非標準であり、ファイルビューアやダンプツールなどのGNU以外のPE対応ツールで調べると、混乱を招く出力が発生する可能性があります。ただし、GDBは、実行可能イメージ内でDwarf-2デバッグ情報セクションを見つけるために、PEの長いセクション名の使用に依存しており、コマンドラインでどちらかのオプションが指定されていない場合、ldは長いセクション名を有効にし、デフォルトの技術的に正しい動作をオーバーライドします。これは、リンク中にデバッグ情報を見つけてシンボルをストリップしない場合に発生します。[このオプションは、PEをターゲットとするすべてのリンカのポートで有効です]

--enable-stdcall-fixup
--disable-stdcall-fixup

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

--leading-underscore
--no-leading-underscore

ほとんどのターゲットでは、デフォルトのシンボルプレフィックスはアンダースコアであり、ターゲットの説明で定義されます。このオプションを使用すると、デフォルトのアンダースコアシンボルプレフィックスを無効化または有効化できます。

--export-all-symbols
指定した場合、DLLの構築に使用されるオブジェクト内のすべてのグローバルシンボルがDLLによってエクスポートされます。DLLにそれ以外の場合エクスポートされるシンボルがない場合、これがデフォルトです。シンボルがDEFファイルまたは関数属性を介して明示的にエクスポートされる場合、デフォルトでは何もエクスポートされません。ただし、このオプションが指定された場合にのみ、他のシンボルもエクスポートされます。"DllMain@12"、"DllEntryPoint@0"、"DllMainCRTStartup@12"、および"impure_ptr"というシンボルは自動的にエクスポートされません。また、他のDLLからインポートされたシンボルは再エクスポートされず、DLLの内部レイアウト("_head_"で始まるシンボルまたは"_iname"で終わるシンボルなど)を指定するシンボルもエクスポートされません。さらに、"libgcc"、"libstd++"、"libmingw32"、または"crtX.o"のシンボルはエクスポートされません。シンボル名が"__rtti_"または"__builtin_"で始まるシンボルは、C++ DLLを支援するためにエクスポートされません。最後に、DLLをCygwinターゲット用にビルドする場合にのみ適用される、エクスポートされない広範なCygwin固有のシンボルがあります。これらの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 シンボル,シンボル,...
自動的にエクスポートされるべきではないシンボルのリストを指定します。シンボル名はカンマまたはコロンで区切ることができます。このオプションは、i386 PEターゲットのリンカーに固有です。

--exclude-all-symbols
シンボルを自動的にエクスポートしないように指定します。このオプションは、i386 PEターゲットのリンカーに固有です。

--file-alignment
ファイルのアラインメントを指定します。ファイル内のセクションは、常にこの数値の倍数のファイルオフセットで始まります。デフォルトは512です。このオプションは、i386 PEターゲットのリンカーに固有です。

--heap reserve
--heap reserve,commit
プログラムで使用するために、予約(およびオプションでコミット)するメモリのバイト数を指定します。デフォルトは、1MB予約、4KBコミットです。このオプションは、i386 PEターゲットのリンカーに固有です。

--kill-at
指定された場合、エクスポート前にシンボルからstdcallサフィックス(@nn)が削除されます。このオプションは、i386 PEターゲットのリンカーに固有です。

--large-address-aware
指定された場合、COFFヘッダーの「特性」フィールド内の適切なビットが設定され、この実行可能ファイルが2ギガバイトを超える仮想アドレスをサポートすることが示されます。これは、[オペレーティングシステム]セクションのBOOT.INIの/3GBまたは/USERVA=値メガバイトスイッチと組み合わせて使用​​する必要があります。それ以外の場合、このビットには効果がありません。このオプションは、PEターゲットのリンカーに固有です。

--disable-large-address-aware
以前の--large-address-awareオプションの効果を打ち消します。これは、--large-address-awareが常にコンパイラドライバ(例:Cygwin gcc)によって設定され、実行可能ファイルが2ギガバイトを超える仮想アドレスをサポートしない場合に役立ちます。このオプションは、PEターゲットのリンカーに固有です。

--major-image-version 値
「イメージバージョン」のメジャー番号を設定します。デフォルトは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

リンカーは、ファイル file を作成し、リンカーが生成している DLL に対応する DEF ファイルを含めます。この DEF ファイル("*.def" と呼ばれる必要があります)は、「dlltool」でインポートライブラリを作成するために使用したり、自動または暗黙的なエクスポートシンボルへの参照として使用したりできます。[このオプションは、i386 PE ターゲットのリンカーに固有です]

--enable-auto-image-base
--enable-auto-image-base=value

DLL のイメージベースを自動的に選択します。必要に応じて、ベース値から開始します。ただし、"--image-base" 引数を使用してイメージベースが指定されている場合は、その値を使用します。dllname から生成されたハッシュを使用して、各 DLL の一意のイメージベースを作成することで、メモリ内の衝突やリロケーションが回避され、プログラムの実行が遅れるのを防ぎます。[このオプションは、i386 PE ターゲットのリンカーに固有です]

--disable-auto-image-base

一意のイメージベースを自動的に生成しないようにします。ユーザーが指定したイメージベース("--image-base")がない場合は、プラットフォームのデフォルトを使用します。[このオプションは、i386 PE ターゲットのリンカーに固有です]

--dll-search-prefix string
インポートライブラリなしで DLL に動的にリンクする場合、"<string><basename>.dll" を "lib<basename>.dll" よりも優先して検索します。この動作により、ネイティブ、Cygwin、uwin、pw などのさまざまな「サブプラットフォーム」用に構築された DLL を簡単に区別できます。たとえば、Cygwin DLL は通常 "--dll-search-prefix=cyg" を使用します。[このオプションは、i386 PE ターゲットのリンカーに固有です]

--enable-auto-import

DLL からの DATA インポートの "_symbol" と "__imp__symbol" の高度なリンクを実行し、ユーザー側で dllimport メカニズムをバイパスして、名前が変更されていないシンボル名を参照できるようにします。[このオプションは、i386 PE ターゲットのリンカーに固有です]

次の注記は、この機能の元の実装に関するものであり、現在は Cygwin および MinGW ターゲットでは廃止されています。

注:'auto-import' 拡張機能を使用すると、イメージファイルのテキストセクションが書き込み可能になります。これは、Microsoft が公開した PE-COFF 形式仕様に準拠していません。

注:auto-import拡張機能を使用すると、通常.rdataセクションに配置される読み取り専用データが、代わりに.dataセクションに配置されます。これは、ここで説明されているconstの問題を回避するためです: http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html

^ uto-importを使用すると、通常は問題なく動作しますが、次のようなメッセージが表示されることがあります。

「変数 '<var>' は自動的にインポートできません。ldの`--enable-auto-import`ドキュメントを参照してください。」

このメッセージは、ある(サブ)式が、最終的に2つの定数の合計によって与えられるアドレスにアクセスする場合に発生します(Win32インポートテーブルは1つしか許可しません)。この問題が発生する可能性のある例としては、DLLからインポートされた構造体変数のメンバーフィールドへのアクセスや、DLLからインポートされた配列変数への定数インデックスを使用したアクセスなどがあります。多語変数(配列、構造体、long longなど)も、このエラー条件を引き起こす可能性があります。ただし、問題のあるエクスポートされた変数の正確なデータ型に関わらず、ldはこれを検出し、警告を発行して終了します。

この問題に対処する方法はいくつかあり、エクスポートされた変数のデータ型に関係なく適用できます。

1つの方法は、--enable-runtime-pseudo-relocスイッチを使用することです。これにより、クライアントコード内の参照の調整タスクが実行時の環境に委ねられるため、この方法は、実行時環境がこの機能をサポートする場合にのみ機能します。

2番目の解決策は、いずれかの「定数」を、コンパイル時に不明で最適化できない変数にすることです。配列の場合、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番目の方法は、「auto-import」を問題のあるシンボルに使用せず、`__declspec(dllimport)`でマークすることです。ただし、実際には、DLLをビルドしているか、DLLにリンクするクライアントコードをビルドしているか、または単に静的ライブラリにビルド/リンクしているかを、コンパイル時の`#define`を使用して指定する必要があります。「定数オフセットを持つ直接アドレス」の問題を解決するためのさまざまな方法を選択する際には、典型的な実際の使用状況を考慮する必要があります。

オリジナル:

--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){
/* これはwin32およびcygwin用です。最適化しないでください */
volatile int *parr = arr;
printf("%d\n",parr[1]);
}

ソリューション2:

--foo.h
/* 自動エクスポートを前提とします(__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()アクセサー関数)を使用してライブラリを再コーディングすることです。

--disable-auto-import
DLLからのDATAインポートに対して、「\_symbol」を「\_\_imp\_\_symbol」に高度にリンクしようとしないでください。[このオプションは、i386 PEターゲットのリンカーに固有のものです]

--enable-runtime-pseudo-reloc
コードに、--enable-auto-importセクションで説明されている式(つまり、ゼロ以外のオフセットを持つDLLからのDATAインポート)が含まれている場合、このスイッチは「ランタイム疑似リロケーション」のベクトルを作成し、ランタイム環境でクライアントコード内のそのようなデータへの参照を調整するために使用できます。[このオプションは、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予約、4KBコミットです。[このオプションは、i386 PEターゲットのリンカーに固有のものです]

--subsystem which
--subsystem which:major
--subsystem which:major.minor
プログラムが実行されるサブシステムを指定します。有効な値は、「native」、「windows」、「console」、「posix」、および「xbox」です。オプションで、サブシステムのバージョンも設定できます。数値もwhichに使用できます。[このオプションは、i386 PEターゲットのリンカーに固有のものです]

次のオプションは、PEファイルのヘッダーの「DllCharacteristics」フィールドのフラグを設定します。
[これらのオプションは、PEターゲットのリンカーに固有のものです]

--high-entropy-va
--disable-high-entropy-va

イメージは、64ビットのアドレス空間レイアウトランダム化(ASLR)と互換性があります。 このオプションは、MinGWターゲットの64ビットPEイメージに対してデフォルトで有効になっています。

このオプションは、--dynamicbaseと--enable-reloc-sectionも暗黙的に有効にします。

--dynamicbase
--disable-dynamicbase

イメージのベースアドレスは、アドレス空間レイアウトランダム化(ASLR)を使用して再配置できます。 この機能は、i386 PEターゲット向けにMS Windows Vistaで導入されました。 このオプションは、MinGWターゲットに対してデフォルトで有効になっていますが、--disable-dynamicbaseオプションを使用して無効にできます。 このオプションは、--enable-reloc-sectionも暗黙的に有効にします。

--forceinteg
--disable-forceinteg

コード整合性チェックが強制されます。 このオプションは、デフォルトでは無効になっています。

--nxcompat
--disable-nxcompat

イメージは、データ実行防止(DEP)と互換性があります。 この機能は、i386 PEターゲット向けにMS Windows XP SP2で導入されました。 このオプションは、MinGWターゲットに対してデフォルトで有効になっています。

--no-isolation
--disable-no-isolation

イメージは分離を理解していますが、イメージを分離しないでください。 このオプションは、デフォルトでは無効になっています。

--no-seh
--disable-no-seh

イメージはSEHを使用しません。 このイメージからSEHハンドラを呼び出すことはできません。 このオプションは、デフォルトでは無効になっています。

--no-bind
--disable-no-bind

このイメージをバインドしないでください。 このオプションは、デフォルトでは無効になっています。

--wdmdriver
--disable-wdmdriver

ドライバーはMS Windows Driver Modelを使用します。 このオプションは、デフォルトでは無効になっています。

--tsaware
--disable-tsaware

イメージはターミナルサーバーに対応しています。 このオプションは、デフォルトでは無効になっています。

--insert-timestamp
--no-insert-timestamp

イメージに実際のタイムスタンプを挿入します。 これはデフォルトの動作であり、従来のコードと一致し、他の独自のツールで機能します。 ただし、このデフォルトでは、同じソースがリンクされるたびに、わずかに異なるイメージが生成されます。 --no-insert-timestampオプションを使用して、タイムスタンプにゼロ値を挿入することで、同一のソースから生成されたバイナリが完全に一致するようにすることができます。

--insert-timestampがアクティブになっている場合、挿入される時間は、リンクが行われる時間、または「SOURCE_DATE_EPOCH」環境変数が定義されている場合は、その変数が指定するUnixエポックからの秒数です。

--enable-reloc-section
--disable-reloc-section

ベース再配置テーブルを作成します。これは、イメージがPEヘッダーで指定されたものとは異なるイメージベースでロードされた場合に必要です。 このオプションは、デフォルトで有効になっています。

C6X uClinuxターゲットは、共有ライブラリをサポートするために、DSBTと呼ばれるバイナリ形式を使用します。 システム内の各共有ライブラリには一意のインデックスが必要であり、すべての実行可能ファイルはインデックス0を使用します。

--dsbt-size size

このオプションは、現在の実行可能ファイルまたは共有ライブラリのDSBT内のエントリ数をsizeに設定します。 デフォルトでは、64エントリのテーブルが作成されます。


--dsbt-index index

このオプションは、現在の実行ファイルまたは共有ライブラリの DSBT インデックスを index に設定します。デフォルトは 0 で、これは実行ファイルの生成に適しています。共有ライブラリが DSBT インデックス 0 で生成された場合、「R_C6000_DSBT_INDEX」リロケーションが出力ファイルにコピーされます。

--no-merge-exidx-entries

このスイッチは、フレームアンワインド情報内の隣接する exidx エントリのマージを無効にします。

--branch-stub

このオプションは、必要な場合にブランチスタブセクションを挿入することで、リンカのブランチリラックスを有効にします。これは、C-SKY はメモリ全体にアクセスできるブランチおよびコール命令をサポートし、ブランチリラックスは通常、コンパイラまたはアセンブラによって処理されるため、通常は必要ありません。

--stub-group-size=N

このオプションを使用すると、リンカのブランチスタブの作成をより細かく制御できます。ブランチによって処理できる入力セクションのグループの最大サイズを N に設定します。N の負の値は、スタブセクションをブランチの後に配置し、正の値は、スタブセクションをブランチの前または後に配置できるようにします。1 または -1 の値は、リンカが適切なデフォルトを選択することを示します。

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

--no-trampoline

このオプションは、トランポリンの生成を無効にします。デフォルトでは、ファーステップ関数が「jsr」命令を使用して呼び出されるたびに(これはファーステップ関数へのポインタが取得された場合に発生します)、トランポリンが生成されます。

--bank-window name

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

次のオプションは、68K ターゲットのリンケージ時に GOT 生成を制御するためにサポートされています。

--got=type

このオプションは、リンカに、使用する GOT 生成スキームを指示します。type は、single、negative、multigot、または target のいずれかである必要があります。詳細については、ld の Info エントリを参照してください。

次のオプションは、MIPS ターゲットのリンケージ時に、マイクロMIPS 命令の生成と ISA モード間の移行に対するブランチリロケーションチェックを制御するためにサポートされています。

--insn32
--no-insn32

これらのオプションは、リンカによって生成されたコードで使用されるマイクロMIPS 命令の選択を制御します。これには、PLT または遅延バインディングスタブ内のコード、またはリラックス時に生成されるコードが含まれます。--insn32 が使用される場合、リンカは 32 ビット命令エンコーディングのみを使用します。デフォルトまたは --no-insn32 が使用される場合、可能な場合は 16 ビットエンコーディングを含むすべての命令エンコーディングが使用されます。

--ignore-branch-isa
--no-ignore-branch-isa

これらのオプションは、無効な ISA モード移行に対するブランチリロケーションチェックを制御します。--ignore-branch-isa が使用される場合、リンカはすべてのブランチリロケーションを受け入れ、関連する ISA モード移行はリロケーション計算で失われます。ただし、「BAL」命令の一部については、リラックス条件を満たし、等価な「JALX」命令に変換される例外があります。関連するリロケーションは計算されます。デフォルトまたは --no-ignore-branch-isa が使用される場合、チェックが実行され、ISA モード移行の損失によりエラーが発生します。


--compact-branches
--no-compact-branches

これらのオプションは、MIPS R6のPLTエントリでリンカがコンパクトな命令を生成するかどうかを制御します。

pdp11-aoutターゲットの場合、次のオプションで3つの出力形式のバリアントを生成できます。pdp11-aoutのデフォルトのバリアントは--omagicオプションであり、他のターゲットの場合は--nmagicがデフォルトです。--imagicオプションはpdp11-aoutターゲットでのみ定義され、他のオプションはここではpdp11-aoutターゲットに適用される方法として説明します。

-N
--omagic

出力ファイルのアウトプットヘッダーに「OMAGIC」(0407)としてマークし、テキストセグメントが書き込み保護されず、共有されないことを示します。テキストセクションとデータセクションの両方が読み取りおよび書き込み可能であるため、データセクションはテキストセグメントの直後に連続して割り当てられます。これは、PDP11実行可能プログラムの最も古い形式であり、PDP11 Unixシステムの最初から2.11BSDまでのldのデフォルトです。

-n
--nmagic

出力ファイルが実行されたときに、テキスト部分が読み取り専用になり、同じファイルを実行するすべてのプロセス間で共有されるように、「NMAGIC」(0410)として出力ファイルのアウトプットヘッダーにマークします。これには、テキストの終了後の最初の可能な8KBのページ境界まで、データ領域を移動させることが含まれます。このオプションは、純粋な実行可能形式を作成します。

-z
--imagic

出力ファイルが実行されたときに、プログラムのテキストとデータ領域が、より大きなPDP11モデルのメモリ管理ユニットの分割命令とデータスペース機能を使用して、別のアドレス空間にロードされるように、「IMAGIC」(0411)として出力ファイルのアウトプットヘッダーにマークします。これにより、プログラムで使用できるアドレス空間が2倍になります。テキストセグメントは、再び純粋で、書き込み保護され、共有されます。このオプションと他のオプションとの出力形式の違いは、マジック番号に加えて、テキストセクションとデータセクションの両方が場所0で開始されることです。-zオプションは、2.11BSDでこの形式を選択しました。このオプションは、分離された実行可能形式を作成します。

--no-omagic

pdp11-aoutの場合は、--nmagicと同等です。

環境

環境変数「GNUTARGET」、「LDEMULATION」、および「COLLECT_NO_DEMANGLE」を使用して、ldの動作を変更できます。

「GNUTARGET」は、-b(またはその同義語--format)を使用しない場合に、入力ファイルオブジェクト形式を決定します。その値は、入力形式のBFD名である必要があります。もし「GNUTARGET」が環境に設定されていない場合、ldはターゲットのネイティブ形式を使用します。もし「GNUTARGET」が「default」に設定されている場合、BFDはバイナリ入力ファイルを調べて入力形式を検出しようとします。この方法はしばしば成功しますが、オブジェクトファイル形式を指定するために使用されるマジック番号が一意であることを保証する方法がないため、潜在的な曖昧さがあります。ただし、各システムでのBFDの構成手順では、そのシステムの従来の形式が検索リストの最初に配置されるため、曖昧さは慣例を優先するように解決されます。

「LDEMULATION」は、-mオプションを使用しない場合に、デフォルトのエミュレーションを決定します。エミュレーションは、特にデフォルトのリンカースクリプトなど、リンカの動作のさまざまな側面に影響を与える可能性があります。利用可能なエミュレーションは、--verboseまたは-Vオプションで一覧表示できます。-mオプションが使用されず、「LDEMULATION」環境変数が定義されていない場合、デフォルトのエミュレーションは、リンカの構成方法によって異なります。

通常、リンカはデフォルトでシンボルのデマンリングを行います。ただし、「COLLECT_NO_DEMANGLE」が環境変数に設定されている場合、シンボルのデマンリングを行わないようにデフォルト設定されます。この環境変数は、「gcc」リンカラッパープログラムでも同様の方法で使用されます。デフォルト設定は、--demangleおよび--no-demangleオプションでオーバーライドできます。

PE/COFF固有の--insert-timestampが有効になっており、「SOURCE_DATE_EPOCH」環境変数が定義されている場合、この変数のタイムスタンプ値がCOFFヘッダーに挿入され、現在の時間が使用されます。

「LD_STATS」環境変数が定義されている場合、リンカのリソース使用情報が記録され、--statsオプションを使用した場合と同じになります。「LD_STATS」変数の値が文字列の場合、この文字列が情報が保存されるファイル名として使用されます。それ以外の場合、情報は標準出力ストリームに送信されます。

関連項目

ar(1)、nm(1)、objcopy(1)、objdump(1)、readelf(1)、およびInfoエントリのbinutilsとld。

著作権

Copyright (c) 1991-2025 Free Software Foundation, Inc.

このドキュメントは、GNUフリードキュメンテーションライセンスバージョン1.3、またはFree Software Foundationによって公開されたそれ以降のバージョンの条件に従って、コピー、配布、および/または修正することを許可します。不変セクション、フロントカバーテキスト、およびバックカバーテキストはありません。ライセンスのコピーは、「GNUフリードキュメンテーションライセンス」というセクションに記載されています。