リンケージは、ライブラリを参照するオブジェクトファイルの前にライブラリを消費します
- プログラムをコンパイルしてGCCツールチェーンにリンクしようとしています。
- リンケージは、必要なすべてのライブラリとライブラリ検索パスを指定します
- に
libfoo依存している場合libbar、リンケージはのlibfoo前に正しく置かれますlibbar。
- あなたの連結はして失敗し
undefined reference to 、何かのエラー。
- ただし、未定義の何かはすべて、ヘッダーファイルで宣言されて
#includeおり、実際には、リンクしているライブラリで定義されています。
例はCにあります。C++も同様に可能です。
自分で作成した静的ライブラリを含む最小限の例
my_lib.c
#include "my_lib.h"
#include <stdio.h>
void hw(void)
{
puts("Hello World");
}
my_lib.h
#ifndef MY_LIB_H
#define MT_LIB_H
extern void hw(void);
#endif
eg1.c
#include <my_lib.h>
int main()
{
hw();
return 0;
}
静的ライブラリを構築します。
$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o
プログラムをコンパイルします。
$ gcc -I. -c -o eg1.o eg1.c
あなたはそれをリンクしてlibmy_lib.a失敗しようとします：
$ gcc -o eg1 -L. -lmy_lib eg1.o
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
次のように、コンパイルとリンクを1つのステップで行った場合も同じ結果になります。
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
共有システムライブラリ、圧縮ライブラリを含む最小限の例 libz
eg2.c
#include <zlib.h>
#include <stdio.h>
int main()
{
printf("%s\n",zlibVersion());
return 0;
}
プログラムをコンパイルします。
$ gcc -c -o eg2.o eg2.c
プログラムをリンクしlibzて失敗します：
$ gcc -o eg2 -lz eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
一度にコンパイルしてリンクする場合も同じです。
$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
例2のバリエーションはpkg-config次のとおりです。
$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
何が悪いの？
プログラムを作成するためにリンクするオブジェクトファイルとライブラリのシーケンスでは、それらを参照するオブジェクトファイルの前にライブラリを配置します。後にライブラリを配置する必要がありますを参照するオブジェクトファイルのます。
例1を正しくリンクします。
$ gcc -o eg1 eg1.o -L. -lmy_lib
成功：
$ ./eg1
Hello World
例2を正しくリンクします。
$ gcc -o eg2 eg2.o -lz
成功：
$ ./eg2
1.2.8
例2のpkg-configバリエーションを正しくリンクします。
$ gcc -o eg2 eg2.o $(pkg-config --libs zlib)
$ ./eg2
1.2.8
説明
これ以降の読み取りはオプションです。
デフォルトでは、ディストリビューションでGCCによって生成されたリンケージコマンドは、リンケージ内のファイルをコマンドラインシーケンスで左から右に消費します。ファイルが何かを参照していることが判明した場合
を参照していて、その定義が含まれていない場合、toはさらに右側のファイル内の定義を検索します。最終的に定義が見つかった場合、参照は解決されます。最後に参照が未解決のままである場合、リンケージは失敗します。リンカーは後方検索を行いません。
最初に、静的ライブラリを使用した例1my_lib.a
静的ライブラリは、オブジェクトファイルのインデックス付きアーカイブです。リンカが-lmy_libリンケージシーケンスで見つけ、これが静的ライブラリを参照している./libmy_lib.aことを理解した場合、リンカはプログラムにのオブジェクトファイルが必要かどうかを知りたいと考えますlibmy_lib.a。
libmy_lib.aつまりmy_lib.o、にはオブジェクトファイルだけがあり、で定義されているのmy_lib.oは関数だけhwです。
リンカは、プログラムがmy_lib.oプログラムに参照していることをすでに知っhwていて、プログラムにすでに追加されている1つまたは複数のオブジェクトファイルで、プログラムがすでに必要であると判断し、追加済みのオブジェクトファイルにの定義hw。
これが当てはまる場合、リンカーはmy_lib.oライブラリからのコピーを抽出し、プログラムに追加します。次に、プログラムにはの定義が含まれているためhw、への参照hwが解決されます。
次のようにプログラムをリンクしようとすると：
$ gcc -o eg1 -L. -lmy_lib eg1.o
リンカは 、見たときにeg1.o プログラムに
追加していません-lmy_lib。現時点では見ていませんのでeg1.o。プログラムはまだ何も参照しhwていません。作成するすべての参照が含まれているため、プログラムはまだまったく参照していませんeg1.o。
そのため、リンカはmy_lib.oプログラムに追加せず、それ以上を使用しませんlibmy_lib.a。
次に、を見つけてeg1.o、プログラムに追加します。リンケージシーケンスのオブジェクトファイルは、常にプログラムに追加されます。これで、プログラムはへの参照を作成しhw、の定義を含みませんhw。ただし、リンケージシーケンスには、定義が不足している可能性のあるものは何も残っていません。参照するhwまで終了し、未解決、および結合は失敗します。
2番目、例2、共有ライブラリlibz
共有ライブラリは、オブジェクトファイルなどのアーカイブではありません。これは、関数を持たず、代わりにそれが定義する他の複数のシンボルを公開するプログラムに非常によく似ているmainため、他のプログラムは実行時にそれらを使用できます。
多くのLinuxディストリビューションは本日、言語ドライバ（ように彼らのGCCツールチェーンを構成しgcc、g++、gfortran（システムリンカに指示など）ldリンクに）上の共有ライブラリなど、必要に応じて基礎。それらのディストリビューションの1つを入手しました。
これは、リンカが-lzリンケージシーケンスで見つかり、これが共有ライブラリ（たとえば）を/usr/lib/x86_64-linux-gnu/libz.so参照していることが判明した場合、プログラムに追加されている未定義の参照に、次のような定義があるかどうかを知りたいという意味ですによってエクスポートされたlibz
これが真の場合、リンカーはチャンクをコピーしてプログラムに追加しませんlibz。代わりに、それはあなたのプログラムのコードを単にドクターします：
プログラムは、によってエクスポートされた定義を持つ1つのものlibz、つまりでzlibVersion一度だけ参照される関数を参照する必要がありeg2.cます。リンカがその参照をプログラムに追加し、によってエクスポートされた定義を見つけたlibz場合、参照は解決されます
しかし、次のようにプログラムをリンクしようとすると、
gcc -o eg2 -lz eg2.o
イベントの順序は、リンカー発見時点で、実施例1と同様に、ちょうど同じように間違っている-lz、存在しない全く彼らはで全てです：プログラムで何かへの参照eg2.o、まだ見ていません。そのため、リンカはを使用しないと判断しますlibz。に到達しeg2.o、それをプログラムに追加した後、への未定義の参照があるzlibVersionと、リンケージシーケンスは終了します。その参照は解決されず、リンケージは失敗します。
最後に、pkg-config例2 のバリエーションには今や明白な説明があります。シェル展開後：
gcc -o eg2 $(pkg-config --libs zlib) eg2.o
になる：
gcc -o eg2 -lz eg2.o
これもまた例2です。
例1では問題を再現できますが、例2では再現できません
リンケージ：
gcc -o eg2 -lz eg2.o
うまくいきます！
（または、そのリンケージはFedora 23などではうまく機能しましたが、Ubuntu 16.04では失敗します）
これは、リンケージが機能するディストリビューションが、共有ライブラリを必要に応じてリンクするようにGCCツールチェーンを構成しないディストリビューションの1つだからです。
かつて、UNIXライクなシステムでは、静的ライブラリと共有ライブラリを異なるルールでリンクするのが普通でした。リンケージシーケンスの静的ライブラリは、例1で説明した必要に応じてリンクされましたが、共有ライブラリは無条件にリンクされました。
リンカはプログラムで共有ライブラリが必要かどうかを考える必要がないため、この動作はリンク時に経済的です。共有ライブラリの場合はリンクします。そして、ほとんどのリンケージのほとんどのライブラリは共有ライブラリです。しかし、欠点もあります：-
実行時に共有ライブラリを必要としない場合でも、プログラムと一緒に読み込まれる可能性があるため、これは実行時に不経済です。
静的ライブラリと共有ライブラリの異なるリンケージルール-lfooは、リンケージがに解決されるの/some/where/libfoo.aかに解決されるのか/some/where/libfoo.soわからず、共有ライブラリと静的ライブラリの違いを理解できない未熟なプログラマを混乱させる可能性があります。
このトレードオフは、今日の分裂的な状況につながっています。一部のディストリビューションでは、必要に応じて
原則をすべてのライブラリに適用できるように、共有ライブラリのGCCリンケージルールを変更しています。一部のディストリビューションは古い方法に固執しています。
コンパイルとリンクを同時に行ってもこの問題が発生するのはなぜですか？
私がやった場合：
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
確かにeg1.c最初にgccをコンパイルしてから、結果のオブジェクトファイルをにリンクする必要がありますlibmy_lib.a。それでは、リンクを行うときにオブジェクトファイルが必要であることをどのようにして知ることができないのでしょうか。
単一のコマンドでコンパイルおよびリンクしても、リンケージシーケンスの順序は変更されないためです。
上記のコマンドを実行すると、gccコンパイル+リンケージが必要であることがわかります。だから、舞台裏、それはコンパイルコマンドを生成し、それを実行し、その後、リンクコマンドを生成し、そしてかのように、それを実行し、あなたが 2つのコマンドを実行していました：
$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o
だから、リンケージは、あなたがあればそれと同じように失敗しないこれらの2つのコマンドを実行します。この失敗で気が付く唯一の違いは、gccがcompile + linkの場合に一時オブジェクトファイルを生成したことですeg1.o。これは、使用するように指示していないためです。私たちは見る：
/tmp/ccQk1tvs.o: In function `main'
の代わりに：
eg1.o: In function `main':
こちらもご覧ください
相互に依存するリンクライブラリが指定されている順序が間違っている
相互に依存するライブラリを間違った順序で配置することは、リンケージの中で、定義を提供するファイルよりも後に来るものの定義を必要とするファイルを取得できる1つの方法にすぎません。ライブラリを参照するオブジェクトファイルの前にライブラリを置くことも、同じ間違いを犯す別の方法です。