最近在Linux下程式設計發現一個詭異的現象，就是在連結一個靜態庫的時候總是報錯，類似下面這樣的錯誤：

1. (.text+0x13): undefined reference to `func' 

    關於undefined reference這樣的問題，大家其實經常會遇到，在此，我以詳細地示例給出常見錯誤的各種原因以及解決方法，希望對初學者有所幫助。

1.  連結時缺失了相關目標檔案（.o）

測試程式碼如下：

    然後編譯。

1. gcc -c test.c  
2. gcc –c main.c 

    得到兩個 .o 檔案，一個是 main.o，一個是 test.o ，然後我們連結 .o 得到可執行程式：

1. gcc -o main main.o 

    這時，你會發現，報錯了：

1. main.o: In function `main':  
2. main.c:(.text+0x7): undefined reference to `test'  
3. collect2: ld returned 1 exit status 

    這就是最典型的undefined reference錯誤，因為在連結時發現找不到某個函式的實現檔案，本例中test.o檔案中包含了test()函式的實現，所以如果按下面這種方式連結就沒事了。

1. gcc -o main main.o test.o 

   【擴充套件】：其實上面為了讓大家更加清楚底層原因，我把編譯連結分開了，下面這樣編譯也會報undefined reference錯，其實底層原因與上面是一樣的。

1. gcc -o main main.c //缺少test()的實現檔案 

需要改成如下形式才能成功，將test()函式的實現檔案一起編譯。

1. gcc -o main main.c test.c //ok,沒問題了 

2.    連結時缺少相關的庫檔案（.a/.so）

    在此，只舉個靜態庫的例子，假設原始碼如下。

    先把test.c編譯成靜態庫(.a)檔案

1. gcc -c test.c  
2. ar -rc test.a test.o 

    至此，我們得到了test.a檔案。我們開始編譯main.c

1. gcc -c main.c 

    這時，則生成了main.o檔案，然後我們再通過如下命令進行連結希望得到可執行程式。

1. gcc -o main main.o 

    你會發現，編譯器報錯了：

1. /tmp/ccCPA13l.o: In function `main':  
2. main.c:(.text+0x7): undefined reference to `test'  
3. collect2: ld returned 1 exit status 

    其根本原因也是找不到test()函式的實現檔案，由於該test()函式的實現在test.a這個靜態庫中的，故在連結的時候需要在其後加入test.a這個庫，連結命令修改為如下形式即可。

1. gcc -o main main.o ./test.a  //注：./ 是給出了test.a的路徑 

     【擴充套件】：同樣，為了把問題說清楚，上面我們把程式碼的編譯連結分開了，如果希望一次性生成可執行程式，則可以對main.c和test.a執行如下命令。

1. gcc -o main main.c ./test.a  //同樣，如果不加test.a也會報錯 

3.    連結的庫檔案中又使用了另一個庫檔案

    這種問題比較隱蔽，也是我最近遇到的與網上大家討論的不同的問題，舉例說明如下，首先，還是看看測試程式碼。

    從上圖可以看出，main.c呼叫了test.c的函式，test.c中又呼叫了fun.c的函式。
    首先，我們先對fun.c，test.c，main.c進行編譯，生成 .o檔案。

1. gcc -c func.c  
2. gcc -c test.c  
3. gcc -c main.c 

    然後，將test.c和func.c各自打包成為靜態庫檔案。

1. ar –rc func.a func.o  
2. ar –rc test.a test.o 

    這時，我們準備將main.o連結為可執行程式，由於我們的main.c中包含了對test()的呼叫，因此，應該在連結時將test.a作為我們的庫檔案，連結命令如下。

1. gcc -o main main.o test.a 

    這時，編譯器仍然會報錯，如下：

1. test.a(test.o): In function `test':  
2. test.c:(.text+0x13): undefined reference to `func'  
3. collect2: ld returned 1 exit status 

    就是說，連結的時候，發現我們的test.a呼叫了func()函式，找不到對應的實現。由此我們發現，原來我們還需要將test.a所引用到的庫檔案也加進來才能成功連結，因此命令如下。

1. gcc -o main main.o test.a func.a 

    ok，這樣就可以成功得到最終的程式了。同樣，如果我們的庫或者程式中引用了第三方庫（如pthread.a）則同樣在連結的時候需要給出第三方庫的路徑和庫檔案，否則就會得到undefined reference的錯誤。

4 多個庫檔案連結順序問題

    這種問題也非常的隱蔽，不仔細研究你可能會感到非常地莫名其妙。我們依然回到第3小節所討論的問題中，在最後，如果我們把連結的庫的順序換一下，看看會發生什麼結果？

1. gcc -o main main.o func.a test.a 

    我們會得到如下報錯.

1. test.a(test.o): In function `test':  
2. test.c:(.text+0x13): undefined reference to `func'  
3. collect2: ld returned 1 exit status 

    因此，我們需要注意，在連結命令中給出所依賴的庫時，需要注意庫之間的依賴順序，依賴其他庫的庫一定要放到被依賴庫的前面，這樣才能真正避免undefined reference的錯誤，完成編譯連結。

5. 在c++程式碼中連結c語言的庫

    如果你的庫檔案由c程式碼生成的，則在c++程式碼中連結庫中的函式時，也會碰到undefined reference的問題。下面舉例說明。

    首先，編寫c語言版庫檔案： 

    編譯，打包為靜態庫：test.a

1. gcc -c test.c  
2. ar -rc test.a test.o 

    至此，我們得到了test.a檔案。下面我們開始編寫c++檔案main.cpp

    然後編譯main.cpp生成可執行程式：

1. g++ -o main main.cpp test.a 

    會發現報錯：

1. /tmp/ccJjiCoS.o: In function `main': 
2. main.cpp:(.text+0x7): undefined reference to `test()' 
3. collect2: ld returned 1 exit status 

    原因就是main.cpp為c++程式碼，呼叫了c語言庫的函式，因此連結的時候找不到，解決方法：即在main.cpp中，把與c語言庫test.a相關的標頭檔案包含新增一個extern "C"的宣告即可。例如，修改後的main.cpp如下：

1. g++ -o main main.cpp test.a 

    再編譯會發現，問題已經成功解決。

///////////////////////////////////////////////////////////////////////////////////////////

Linux下編譯程式時，經常會遇到“undefined reference to XXX” 報錯，

這裡總結一些可能的原因和解決方案，給需要的朋友：

說道undefined reference error，先提一下Linux gcc連結規則：

連結的時候查詢順序是:

1. -L 指定的路徑, 從左到右依次查詢
2. 由 環境變數 LIBRARY_PATH 指定的路徑,使用":"分割從左到右依次查詢
3. /etc/ld.so.conf 指定的路徑順序
4. /lib 和 /usr/lib (64位下是/lib64和/usr/lib64)

動態庫呼叫的查詢順序:

1. ld的-rpath引數指定的路徑, 這是寫死在程式碼中的
2. ld指令碼指定的路徑
3. LD_LIBRARY_PATH 指定的路徑
4. /etc/ld.so.conf 指定的路徑
5. /lib和/usr/lib(64位下是/lib64和/usr/lib64)

一般情況連結的時候我們採用-L的方式指定查詢路徑, 呼叫動態連結庫的時候採用LD_LIBRARY_PATH的方式指定連結路徑.

另外注意一個問題,就是隻要查詢到第一個就會返回,後面的不會再查詢. 比如-L./A -L./B -lx 在A中有libx.a B中有libx.a和libx.so, 這個時候會使用在./A的libx.a 而不會遵循動態庫優先的原則,因為./A是先找到的,並且沒有同名動態庫存在

對於動態連結庫，實際的符號定位是在執行期進行的．在編譯.so的時候，如果沒有把它需要的庫和他一起進行聯編，比如libx.so 需要使用uldict, 但是忘記在編譯libx.so的時候加上-luldict的話，在編譯libx.so的時候不會報錯，因為這個時候libx.so被認為是一個庫，它裡面存在一些不知道具體實現的符號是合法的，是可以在執行期指定或者編譯另外的二進位制程式的時候指定．

如果是採用　g++ -Lpath -lx 的方式進行編譯，連結器會發現所需要的uldict的符號表找不到從而報錯，但是如果是程式採用dlopen的方式載入，由於是執行期，這個程式在這個地方就直接執行報錯了．另外還有一種情況就是一個對外的介面在動態庫中已經宣告定義了，但是忘記實現了，這個時候也會產生類似的錯誤．

如果在執行期報出這樣的錯誤，就要注意是否是由於某些庫沒有連結進來或者某些介面沒有實現的原因產生

有了上述基礎，不難看出，undefined reference error錯誤的原因是：

1. 沒有指定對應的庫（.o/.a/.so） 使用了庫中定義的實體，但沒有指定庫（-lXXX）或者沒有指定庫路徑（-LYYY），會導致該錯誤,
2. 連線庫引數的順序不對 在預設情況下,對於-l 使用庫的要求是越是基礎的庫越要寫在後面,無論是靜態還動態
3. gcc/ld 版本不匹配 gcc/ld的版本的相容性問題,由於gcc2 到 gcc3大版本的相容性存在問題(其實gcc3.2到3.4也一定程度上存在這樣的問題) 當在高版本機器上使用低版本的機器就會導致這樣的錯誤, 這個問題比較常見在32位的環境上, 另外就在32位環境不小心使用了64位的庫或者反過來64位環境使用了32位的庫.
4. C/C++相互依賴和連結 gcc和g++編譯結果的混用需要保證能夠extern "C" 兩邊都可以使用的介面,在我們的64位環境中gcc連結g++的庫還需要加上 -lstdc++,具體見前文對於混合編譯的說明
5. 執行期報錯 這個問題基本上是由於程式使用了dlopen方式載入.so, 但.so沒有把所有需要的庫都連結上,具體參加上文中對於靜態庫和動態庫混合使用的說明