GCCでライブラリのリンク順序によってエラーが発生するのはなぜ？原因と解決策を徹底解説

GCCでコンパイルを行う際、「undefined reference（未定義参照）」といったリンクエラーが、ライブラリを指定する順序によって発生したり消えたりすることがあります。これはコンパイラ本体の問題ではなく、リンカ（ld）のデフォルトの動作に起因するものです。

リンカは「必要になった時点」でしかアーカイブを読み込まない

リンカは、コマンドラインで渡されたファイルを基本的に左から右へ順番に処理します。アーカイブライブラリ（.a ファイル）に対しては、「その時点で未解決になっているシンボル」を満たすメンバーだけを取り込むのがデフォルトの挙動です。

重要なのは、リンカが一度読み飛ばしたシンボルには後から戻らないという点です。そのため、まだ要求されていない段階でライブラリが登場すると、そこにあるシンボルは取り込まれず、結果として未解決参照が残ってしまいます。

基本原則は「呼び出し元が先、呼び出される側が後」

静的ライブラリを正しくリンクするには、ライブラリを 「caller（呼び出し元）が先、callee（呼び出される側）が後」 の順序で並べる必要があります。例えば、libfoo が libbar の関数を利用している場合は次のように指定します。

gcc main.o -lfoo -lbar

逆の順序（-lbar -lfoo）にすると、-lbar を処理した時点では libfoo からの参照がまだ未解決になっていないため、必要なオブジェクトが取り込まれず、エラーにつながります。

解決策1：ライブラリの順序を正しく並べ替える

最も確実な方法は、依存関係に従ってライブラリの並び順を修正することです。規模が大きく依存関係が複雑なプロジェクトでは、伝統的なUNIXツールである lorder と tsort を組み合わせると、オブジェクト間の依存関係から適切なリンク順序を自動的に求められます。

解決策2：リンカオプションで繰り返し探索させる

順序を手作業で調整したくない場合は、非デフォルトの動作をリンカフラグで指定する方法もあります。--start-group と --end-group（省略形は -( と -)）でライブラリ群を囲むと、リンカはグループ内のアーカイブを循環的に探索し、すべての参照が解決するまで繰り返し読み込みます。

gcc main.o -Wl,--start-group -lfoo -lbar -Wl,--end-group

ただしこの方法では、リンカが同じアーカイブを何度も走査するため、リンクにかかる時間が長くなるというトレードオフがあります。大規模なビルドでは注意が必要です。

補足：共有ライブラリの場合

なお、共有ライブラリ（.so ファイル）を使用する場合は、シンボルが実行時に動的に解決されるため、静的ライブラリほど厳密な順序管理は求められません。リンク順序の問題は主に静的アーカイブ（.a）を扱う際に顕在化します。