特別なファイルの命名規則をライブラリーに使用します。foo として知られるライブラリーは、libfoo.so ファイルまたは libfoo.a ファイルとして存在する必要があります。この規則は、リンクする GCC の入力オプションでは自動的に理解されますが、出力オプションでは理解されません。

開発者は、完全にコンパイルされた言語でアプリケーションを構築する際に、静的リンクまたは動的リンクを使用できます。特に Red Hat Enterprise Linux で C および C++ 言語を使用するコンテキストでは、静的リンクと動的リンクの違いを理解することが重要です。Red Hat は、Red Hat Enterprise Linux のアプリケーションで静的リンクを使用することは推奨していません。

動的リンクおよび静的リンクは、いくつかの点で異なります。

上述のデメリットにより、静的リンクは、特にアプリケーション全体、glibc ライブラリー、および libstdc++ ライブラリーに対しては、使用しないようにしてください。

ライブラリーは、プログラムで再利用可能なコードのパッケージです。C または C++ のライブラリーは、以下の 2 つの部分で設定されます。

通常、ライブラリーのヘッダーファイルは、アプリケーションのコードとは別のディレクトリーに配置されます。ヘッダーファイルの場所を GCC に指示するには、-I オプションを使用します。

$ gcc ... -Iinclude_path ...

include_path は、ヘッダーファイルのディレクトリーのパスに置き換えます。

-I オプションは、複数回使用して、ヘッダーファイルを含むディレクトリーを複数追加できます。ヘッダーファイルを検索する場合は、-I オプションで表示順に、これらのディレクトリーが検索されます。

ライブラリーのアーカイブファイルまたは共有オブジェクトファイルの場所を GCC に渡すには、-L オプションを使用します。

$ gcc ... -Llibrary_path -lfoo ...

library_path は、ライブラリーのディレクトリーのパスに置き換えます。

-I オプションは複数回使用して、ディレクトリーを複数追加できます。ライブラリーを検索する場合は、-L オプションで表示順に、このディレクトリーが検索されます。

オプションの指定順は重要です。対象のライブラリーがディレクトリーにリンクされていることが分からないと、GCC は、ライブラリー foo をリンクできません。そのため、-L オプションを使用して先にライブラリーディレクトリーを指定してから、-l オプションでライブラリーをリンクするようにしてください。

静的なライブラリーは、オブジェクトファイルを含むアーカイブとして利用できます。リンクを行うと、作成された実行ファイルの一部となります。

動的ライブラリーは、スタンドアロンの実行ファイルとして提供します。このファイルは、リンク時およびランタイム時に必要です。このファイルは、アプリケーションの実行可能ファイルからは独立しています。

$ gcc ... -Llibrary_path -lfoo ...

プログラムを動的ライブラリーにリンクすると、作成されるプログラムは常にランタイム時にライブラリーを読み込む必要があります。ライブラリーの場所を特定するオプションは 2 つあります。

GCC とリンクし、library_path のパスを rpath として保存します。

$ gcc ... -Llibrary_path -lfoo -Wl,-rpath=library_path ...

library_path のパスは、libfoo.so ファイルを含むディレクトリーを参照する必要があります。

あとでプログラムを実行するには、次のコマンドを実行します。

$ ./program

rpath セットがなく、ライブラリーが library_path パスにある状態で、プログラムを実行します。

$ export LD_LIBRARY_PATH=library_path:$LD_LIBRARY_PATH
$ ./program

rpath の値を空白にすると柔軟性がありますが、プログラムを実行するたびに LD_LIBRARY_PATH 変数を設定する必要があります。

動的リンカーの動作に関する詳細な説明は、本書の対象外です。詳しい情報は、以下の資料を参照してください。

場合によっては、静的ライブラリーと動的ライブラリーの両方をリンクする必要があります。このような場合には、いくつかの課題があります。

このようなルールがあるため、リンクするために、静的ライブラリーまたは動的ライブラリーを選択する場合は、gcc が検索可能なバージョンのみを指定するようにします。これにより、-Lpath オプションで指定する場合に、静的ライブラリーまたは動的ライブラリーを含むディレクトリーを追加するか、追加しないかで、ある程度制御が可能になります。

また、動的リンクがデフォルトの設定であるため、明示的にリンクを指定する必要があるのは、静的と動的の両方を静的にリンクする必要がある場合のみです。考えられる方法は以下の 2 つです。

$ gcc ... path/to/libfoo.a ...

ファイルの拡張子 .a から、gcc は、このファイルがプログラムとリンクするためのライブラリーであることを理解します。ただし、ライブラリーファイルの完全パスを指定するのは柔軟な方法ではありません。

gcc が使用する ld リンカーには、-Bstatic と -Bdynamic のオプションがあり、このオプションの後に来るライブラリーが静的または動的にリンクすべきかどうかを指定します。-Bstatic とライブラリーをリカーに渡した後、以降のライブラリーを -Bdynamic オプションで動的にリンクするには、デフォルトの動的リンクの動作を手動で復元する必要があります。

プログラムをリンクするには、first ライブラリーを静的にリンク (libfirst.a) して、second ライブラリーを動的にリンク (libsecond.so) します。

$ gcc ... -Wl,-Bstatic -lfirst -Wl,-Bdynamic -lsecond ...

特別なファイルの命名規則をライブラリーに使用します。foo として知られるライブラリーは、libfoo.so ファイルまたは libfoo.a ファイルとして存在する必要があります。この規則は、リンクする GCC の入力オプションでは自動的に理解されますが、出力オプションでは理解されません。

動的に読み込んだライブラリー (共有オブジェクト) は、soname と呼ばれるメカニズムを使用して、複数の互換性のあるライブラリーを管理します。

foo ライブラリーの X.Y バージョンは、バージョン番号 (X) が同じ値でマイナーバージョンが異なるバージョンと、ABI の互換性があります。互換性を確保してマイナーな変更を加えると、Y の数字が増えます。互換性がなくなるような、メジャーな変更を加えると、X の数字が増えます。

foo ライブラリーバージョン X.Y は、libfoo.so.x.y ファイルとして存在します。ライブラリーファイルの中に、soname が libfoo.so.x の値として記録され、互換性を指定します。

アプリケーションを構築すると、リンカーが libfoo.so ファイルを検索して、ライブラリーを特定します。この名前のシンボリックリンクが存在し、実際のライブラリーファイルを参照している必要があります。次にリンカーは、ライブラリーファイルから soname を読み込み、アプリケーションの実行ファイルに記録します。最後に、リンカーにより、名前でもファイル名でもなく、soname を使用してライブラリーで依存関係を宣言するアプリケーションが作成されます。

ランタイムの動的リンカーが実行前にアプリケーションをリンクすると、soname がアプリケーションの実行ファイルから読み込まれます。この soname は libfoo.so.x と呼ばれます。この名前のシンボリックリンクが存在し、実際のライブラリーファイルを参照している必要があります。soname が変更しないため、これにより、バージョンの Y コンポーネントに関係なく、ライブラリーを読み込むことができます。

$ objdump -p somelibrary | grep SONAME

somelibrary は、検証するライブラリーのファイル名に置き換えます。

動的にリンクされたライブラリー (共有オブジェクト) では以下が可能です。

以下の手順に従って、ソースから動的ライブラリーを構築してインストールします。

オブジェクトファイルを特別なアーカイブファイルに変換して、静的にリンクするライブラリーを作成できます。

特定のプロジェクトのソースファイルから使用可能な形式 (通常は実行ファイル) を作成するには、必要な手順を完了します。後で繰り返し実行できるように、アクションとそのシーケンスを記録します。

Red Hat Enterprise Linux には、この目的に合わせて設計されたビルドシステムである、GNU make が含まれています。

オプションを指定せずに make を実行すると、現在のディレクトリーで Makefile を検索し、デフォルトのターゲットに到達しようと試みます。実際の Makefile ファイル名は Makefile、makefile、および GNUmakefile です。デフォルトのターゲットは、Makefile の内容で決まります。

通常、Makefile は、ソースファイルをコンパイルするルール、作成されるオブジェクトファイルをリンクするルール、および階層上部のエントリーポイントとしてのロールを果たすターゲットで設定されます。

1 つのファイル (hello.c) で設定される C プログラムを構築する場合は、以下の Makefile を参照してください。

all: hello

hello: hello.o
        gcc hello.o -o hello

hello.o: hello.c
        gcc -c hello.c -o hello.o

この例では、ターゲット all に到達するには、ファイル hello が必要です。hello を取得するには、hello.o (gcc でリンク) が必要で、hello.c (gcc でコンパイル) を基に作成します。

ターゲットの all は、ピリオド (.) で開始されない最初のターゲットであるため、デフォルトのターゲットとなっています。この Makefile が現在のディレクトリーに含まれている場合に、引数なしで make を実行するのは、make all を実行するのと同じです。

CC=gcc
CFLAGS=-c -Wall
SOURCE=hello.c
OBJ=$(SOURCE:.c=.o)
EXE=hello

all: $(SOURCE) $(EXE)

$(EXE): $(OBJ)
        $(CC) $(OBJ) -o $@

%.o: %.c
        $(CC) $(CFLAGS) $< -o $@

clean:
        rm -rf $(OBJ) $(EXE)

このような Makefile にソースファイルを追加する場合は、SOURCE 変数が定義されている行に追加します。

この例の手順に従い、Makefile を使用して C のサンプルプログラムを構築します。

make の詳細は、以下に記載のドキュメントを参照してください。

Red Hat Enterprise Linux 8 では、GCC ツールチェーンは GCC 8.2 リリースシリーズに基づいています。以下は、Red Hat Enterprise Linux 7 からの主な変更点です。

詳細は 「RHEL 8 の GCC へのセキュリティー強化」 を参照してください。

以下では、Red Hat Enterprise Linux 7.0 のリリース以降に追加されたセキュリティーに関連する GCC の変更の詳細を紹介します。

std::string および std::list における C++ ABI の変更

RHEL 7 (GCC 4.8) と RHEL 8 (GCC 8) との間で変更した libstdc++ ライブラリーの std::string クラスおよび std::list クラスの Application Binary Interface (ABI) は、C++11 標準に従います。libstdc++ ライブラリーは、古い ABI および新しい ABI の両方に対応しますが、その他の C++ システムライブラリーには対応しません。そのため、このライブラリーに動的にリンクするアプリケーションを再構築する必要があります。これは、C++98 を含むすべての C++ 標準モードに影響します。RHEL 7 で Red Hat Developer Toolset コンパイラーを使用して構築したアプリケーションにも影響します。このコンパイラーは、古い ABI を維持して、システムライブラリーとの互換性を維持します。

GCC が、Ada、Go、および Objective C/C++ コードを構築しなくなる

GCC コンパイラーから、Ada (GNAT)、GCC Go、および Objective C/C++ の言語でコードを構築する機能が削除されました。

Go コードを構築する場合は、代わりに Go Toolset を使用します。

実行なコードをデバッグしている場合は、2 種類の情報により、ツール、さらにはプログラマーがバイナリーコードを理解できます。

このような情報はデバッグ情報と呼ばれます。

Red Hat Enterprise Linux は、実行可能なバイナリー、共有ライブラリー、または debuginfo ファイルに ELF 形式を使用します。これらの ELF ファイル内では、DWARF 形式を使用してデバッグ情報が維持されます。

ELF ファイルに保存されている DWARF 情報を表示するには、readelf -w file コマンドを実行します。

デバッグの情報が大きいと、デフォルトでは実行ファイルが含まれません。GCC を使用した C および C++ のアプリケーションのデバッグを有効にするには、ファイルを作成するように、コンパイラーに明示的に指定する必要があります。

コードのコンパイルおよびリンク時に、GCC でデバッグ情報の作成を有効にするには、-g オプションを使用します。

$ gcc ... -g ...

debuginfo パッケージおよび debugsource パッケージには、プログラムおよびライブラリーのデバッグ情報と、デバッグソースコードが含まれます。Red Hat Enterprise Linux リポジトリーのパッケージにインストールされているアプリケーションやライブラリーの場合は、追加のチャンネルから個別の debuginfo パッケージおよび debugsource パッケージを取得できます。

デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。

実行ファイルの場所を特定し、インストールするパッケージを見つけることで、インストールする debuginfo パッケージを手動で判断できます。

Red Hat Enterprise Linux には GNU デバッガー (GDB) が含まれ、コマンドラインユーザーインターフェイスを使用して、プログラム内で何が起こっているかを調べることができます。

プロセスを検証するには、GDB がプロセスに 割り当てられている 必要があります。

$ gdb program

program は、ファイル名またはプログラムへのパスに置き換えます。

GDB は、プログラムの実行を開始するように設定します。run コマンドでプロセスの実行を開始する前に、ブレークポイントと gdb 環境を設定できます。

(gdb) file path/to/program

GDB デバッガーがプログラムに割り当てられたら、複数のコマンドを使用して、プログラムの実行を制御できます。

プログラムの内部変数の値を表示することは、プログラムの実行内容を理解する際に重要です。GDB は、内部変数の検査に使用できる複数のコマンドを提供します。これらのコマンドの中で最も有用なものは次のとおりです。

多くの場合、コードの一部のみが検証されます。ブレークポイントは、コード内の特定の場所でプログラムの実行を停止するように GDB に指示を出すマーカーです。ブレークポイントは、ソースコードの行に関連付けられているのが最も一般的です。その場合、ブレークポイントを配置するには、ソースファイルと行番号を指定する必要があります。

多くの場合、特定のデータが変更されたり、アクセスされるまでプログラムを実行させることには利点があります。次の例は、最も一般的な使用例です。

プログラムによっては、フォークまたはスレッドを使用して、並行コード実行を実現します。複数の同時実行パスをデバッグするには、特別な留意点があります。

GDB は、現在のスレッド の概念を使用します。デフォルトでは、コマンドは現在のスレッドのみに適用されます。

Red Hat Enterprise Linux は、アプリケーションの相互作用を分析するための複数のツールを提供しています。

strace ツールは、アプリケーションを実行するシステム (カーネル) コールの監視を有効にします。

$ strace ... |& tee your_log_file.log

ltrace ツールは、ライブラリー (共有オブジェクト) で利用可能な関数へのアプリケーションの呼び出しを監視できます。

$ ltrace ... |& tee your_log_file.log

SystemTap ツールでは、カーネルイベントにカスタムイベントハンドラーを登録できます。strace ツールと比較すると、使用は難しくなりますが、より効率的でより複雑な処理ロジックを使用できます。strace.stp と呼ばれる SystemTap スクリプトは SystemTap と共にインストールされ、SystemTap を使用して strace に類似の機能を提供します。

GNU デバッガー (GDB) により、プログラムの実行中に発生するさまざまな状況で実行を停止できます。プログラムがシステムコールを実行するときに実行を停止するには、GDB の チェックポイント を使用します。

GNU デバッガー (GDB) により、プログラムの実行中に発生するさまざまな状況で実行を停止できます。プログラムがオペレーティングシステムからシグナルを受信するときに実行を停止するには、GDB の キャッチポイント を使用します。

コアダンプは、アプリケーションの動作が停止した時点のアプリケーションのメモリーの一部のコピーで、ELF 形式で保存されます。コアダンプには、アプリケーションの内部変数、スタックすべてが含まれ、アプリケーションの最終的な状態を検査することができます。それぞれの実行可能ファイルおよびデバッグ情報を追加すると、実行中のプログラムを分析するのと同様に、デバッガーでコアダンプファイルを分析できます。

Linux オペレーティングシステムカーネルは、この機能が有効な場合に、コアダンプを自動的に記録できます。または、実行中のアプリケーションにシグナルを送信すると、実際の状態に関係なくコアダンプを生成できます。

$ ulimit -a

アプリケーションのクラッシュを記録するには、コアダンプの保存内容を設定し、システムに関する情報を追加します。

systemd の coredumpctl ツールは、クラッシュが発生したマシン上のコアダンプの処理を大幅に合理化できます。この手順では、応答しないプロセスのコアダンプを取得する方法を説明します。

コアダンプのデバッグのワークフローでは、プログラムの状態をオフラインで分析できます。場合によっては、このプロセスの環境にアクセスするのが困難な場合など、実行中のプログラムでこのワークフローを使用できます。gcore コマンドを使用すると、実行中にプロセスのメモリーをダンプできます。

プロセスのメモリーをダンプしないようにマークできます。これにより、銀行、会計アプリケーション、または仮想マシン全体など、プロセスメモリーに機密データが含まれる場合は、リソースを節約し、セキュリティーを強化できます。カーネルのコアダンプ (kdump) および手動のコアダンプ (gcore、GDB) は、このようにマークされたメモリーをダンプしません。

場合によっては、これらの保護に関係なく、プロセスメモリーの内容全体をダンプする必要があります。この手順では、GDB デバッガーを使用してこれを行う方法を説明します。

GCC Toolset 9 は、以下のツールおよびバージョンを提供します。

GCC Toolset の GCC コンパイラーは、以下の C++ 規格を使用できます。

すべての言語規格は、規格に準拠したバリアントまたは GNU 拡張機能の両方で利用できます。

GCC Toolset で構築されたオブジェクトを、RHEL ツールチェーン (特に .o ファイルまたは ..a ファイル) で構築したオブジェクトと混在する場合、GCC Toolset ツールチェーンはどの連携にも使用する必要があります。これにより、GCC Toolset が提供する新しいライブラリー機能は、リンク時に解決されます。

$ scl enable gcc-toolset-9 'gcc -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-9 'gcc objfile.o -lsomelib'

この推奨事項は、Red Hat Enterprise Linux のベースバージョンの GCC を使用する場合にも適用されることに注意してください。

$ scl enable gcc-toolset-9 'ld -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-9 'ld objfile.o -lsomelib'

また、この推奨事項は、Red Hat Enterprise Linux のベースバージョンの binutils を使用している場合にも適用されることに注意してください。

GCC Toolset 10 は、以下のツールおよびバージョンを提供します。

GCC Toolset の GCC コンパイラーは、以下の C++ 規格を使用できます。

すべての言語規格は、規格に準拠したバリアントまたは GNU 拡張機能の両方で利用できます。

GCC Toolset で構築されたオブジェクトを、RHEL ツールチェーン (特に .o ファイルまたは ..a ファイル) で構築したオブジェクトと混在する場合、GCC Toolset ツールチェーンはどの連携にも使用する必要があります。これにより、GCC Toolset が提供する新しいライブラリー機能は、リンク時に解決されます。

$ scl enable gcc-toolset-10 'gcc -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-10 'gcc objfile.o -lsomelib'

この推奨事項は、Red Hat Enterprise Linux のベースバージョンの GCC を使用する場合にも適用されることに注意してください。

$ scl enable gcc-toolset-10 'ld -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-10 'ld objfile.o -lsomelib'

また、この推奨事項は、Red Hat Enterprise Linux のベースバージョンの binutils を使用している場合にも適用されることに注意してください。

GCC Toolset 11 は、以下のツールおよびバージョンを提供します。

GCC Toolset の GCC コンパイラーは、以下の C++ 規格を使用できます。

すべての言語規格は、規格に準拠したバリアントまたは GNU 拡張機能の両方で利用できます。

GCC Toolset で構築されたオブジェクトを、RHEL ツールチェーン (特に .o ファイルまたは ..a ファイル) で構築したオブジェクトと混在する場合、GCC Toolset ツールチェーンはどの連携にも使用する必要があります。これにより、GCC Toolset が提供する新しいライブラリー機能は、リンク時に解決されます。

$ scl enable gcc-toolset-11 'gcc -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-11 'gcc objfile.o -lsomelib'

この推奨事項は、Red Hat Enterprise Linux のベースバージョンの GCC を使用する場合にも適用されることに注意してください。

$ scl enable gcc-toolset-11 'ld -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-11 'ld objfile.o -lsomelib'

また、この推奨事項は、Red Hat Enterprise Linux のベースバージョンの binutils を使用している場合にも適用されることに注意してください。

GCC Toolset 12 は、以下のツールおよびバージョンを提供します。

GCC Toolset の GCC コンパイラーは、以下の C++ 規格を使用できます。

すべての言語規格は、規格に準拠したバリアントまたは GNU 拡張機能の両方で利用できます。

GCC Toolset で構築されたオブジェクトを、RHEL ツールチェーン (特に .o ファイルまたは ..a ファイル) で構築したオブジェクトと混在する場合、GCC Toolset ツールチェーンはどの連携にも使用する必要があります。これにより、GCC Toolset が提供する新しいライブラリー機能は、リンク時に解決されます。

$ scl enable gcc-toolset-12 'gcc -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-12 'gcc objfile.o -lsomelib'

この推奨事項は、Red Hat Enterprise Linux のベースバージョンの GCC を使用する場合にも適用されることに注意してください。

$ scl enable gcc-toolset-12 'ld -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-12 'ld objfile.o -lsomelib'

また、この推奨事項は、Red Hat Enterprise Linux のベースバージョンの binutils を使用している場合にも適用されることに注意してください。

場合によっては、GCC Toolset 12 における annobin と gcc 間の同期問題により、コンパイルが失敗し、次のようなエラーメッセージが表示されることがあります。

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

この問題を回避するには、プラグインディレクトリーに annobin.so ファイルから gcc-annobin.so ファイルへのシンボリックリンクを作成します。

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# ln -s annobin.so gcc-annobin.so

architecture はシステムでお使いのアーキテクチャーに置き換えてください。

GCC Toolset 13 は、以下のツールおよびバージョンを提供します。

GCC Toolset の GCC コンパイラーは、以下の C++ 規格を使用できます。

すべての言語規格は、規格に準拠したバリアントまたは GNU 拡張機能の両方で利用できます。

GCC Toolset で構築されたオブジェクトを、RHEL ツールチェーン (特に .o ファイルまたは ..a ファイル) で構築したオブジェクトと混在する場合、GCC Toolset ツールチェーンはどの連携にも使用する必要があります。これにより、GCC Toolset が提供する新しいライブラリー機能は、リンク時に解決されます。

$ scl enable gcc-toolset-13 'gcc -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-13 'gcc objfile.o -lsomelib'

この推奨事項は、Red Hat Enterprise Linux のベースバージョンの GCC を使用する場合にも適用されることに注意してください。

$ scl enable gcc-toolset-13 'ld -lsomelib objfile.o'

この方法で GCC Toolset のライブラリーを使用すると、リンカーのエラーメッセージで、シンボルの参照が未定義 になります。この問題を回避するには、標準のリンクプラクティスに従い、オブジェクトファイルを指定するオプションの後に、ライブラリーを追加するオプションを指定します。

$ scl enable gcc-toolset-13 'ld objfile.o -lsomelib'

また、この推奨事項は、Red Hat Enterprise Linux のベースバージョンの binutils を使用している場合にも適用されることに注意してください。

状況によっては、GCC Toolset 13 の annobin と gcc 間の同期の問題が原因で、コンパイルが失敗し、次のようなエラーメッセージが表示されることがあります。

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

この問題を回避するには、プラグインディレクトリーに annobin.so ファイルから gcc-annobin.so ファイルへのシンボリックリンクを作成します。

# cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin
# ln -s annobin.so gcc-annobin.so

architecture はシステムでお使いのアーキテクチャーに置き換えてください。

GCC Toolset 13 コンテナーイメージで提供されるツールバージョンは、GCC Toolset 13 のコンポーネントバージョン と同じです。

次のセクションでは、GCC Toolset コンテナーイメージにアクセスして実行する方法を説明します。

この例では、GCC Toolset 13 Toolchain コンテナーイメージを取得して使用を開始する方法を示します。

次のセクションでは、以下を行う方法を説明します。

次のセクションでは、annocheck を使用して検証する方法を説明します。

annobin を使用すると、バイナリーのサイズが増えます。annobin でコンパイルしたバイナリーのサイズを縮小するには、冗長な annobin ノートを削除できます。冗長する annobin ノートを削除するには、binutils パッケージに含まれる objcopy プログラムを使用します。

場合によっては、GCC Toolset 12 における annobin と gcc 間の同期問題により、コンパイルが失敗し、次のようなエラーメッセージが表示されることがあります。

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

この問題を回避するには、プラグインディレクトリーに annobin.so ファイルから gcc-annobin.so ファイルへのシンボリックリンクを作成します。

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# ln -s annobin.so gcc-annobin.so

architecture はシステムでお使いのアーキテクチャーに置き換えてください。