undefined reference to 問題總結

Table of Contents

• 1 快速解決方案
• 2 從extern說起
• 3 鏈接時符號定位
• 4 解決方案背後的門道
  • 4.1 方法0
  • 4.2 方法1
  • 4.3 方法2
  • 4.4 方法3
• 5 參考

1 快速解決方案

如果你只想立即解決此類問題，那麼：

• 方法0： 首先檢查XXX函數或者符號是否的確包含在命令行用 -l 參數指定的所有庫裏。 你可以通過先簡單的grep XXX 的試試。（grep到XXX，只能代表庫文件中包含該字符串，不等同於有XXX符號的定義。objdump可查看是否真的定義了XXX）。如果找不到，需要先添加相應的鏈接庫選項到命令行中。假如包含XXX的是libaaa.a, 則需要在命令行添加-laaa。另外ld –verbose看看是否庫文件路徑指定正確。如果此招無效，接着往下看。
• 方法1： 不妨在命令的結尾處再添加一次 -laaa 參數試試。
• 方法2： 將-laaa選項用 “-Wl,–start-group ” 和”-Wl, –end-group”括起來試試。(即 “-Wl,–start-group … -laaa … -Wl,–end-group”)
• 方法3： 將命令行所指定的所有庫（尤其是非libgcc.a,libc.a之類的標準庫）用 ar重新打包成一個新的 .a文件試試。

也許以上四個方法能幫你解決問題。如果想了解這背後的門道，請繼續閱讀。

2 從extern說起

我們都知道C語言遵循先聲明、後使用的原則。但爲了支持模塊化編程（即將程序代碼拆分存儲到多個文件中），不同文件中定義的符號可能會相互引用。如A文件中定義了函數XXX，B文件中的代碼可能會調用XXX。在編譯器生成的可執行文件中，需要提供某種支持使得執行到調用XXX的動作時，能自動跳轉到A文件中定義XXX的位置開始執行XXX函數本身。因此編譯器需要知道在可執行文件中XXX的引用點。

理論上編譯器可以將A和B中的代碼先整合成一個文件，並讓XXX定義在前調用在後來解決這一問題。但當代碼量很大時，每次小修改都需要編譯所有代碼，耗時太久。於是爲了更好的支持增量編譯（即每次僅編譯最新修改過的文件），就需要在編譯階段先在XXX的調用點留出一個空槽出來，然後再增加一個鏈接過程，在鏈接的時候找到XXX定義的位置，將這個值填入槽中。

另外語言層面也需要擴展，否則編譯器還會在B文件中傻傻的找XXX的定義，找不到就會報錯。所以extern關鍵字被引入，它告訴編譯器，留個空槽就符號XXX就行了，不要傻找了,這個函數在其他文件中已經定義。不僅僅是函數，其實許多全局的符號都可以聲明成extern，如全局變量。

3 鏈接時符號定位

鏈接時，ld會首先把所有object文件中的相同的段合併，併爲他們分配額空間，這樣每個段中各個符號的定義位置就確定了。接着，ld就會在所有符號的引用點處，將爲符號留下來的”空槽“，填上定義符號的地址。

4 解決方案背後的門道

 

4.1 方法0

因爲命令行確實沒有指出符號所在的庫文件，所以報錯。找到相應庫文件，先添加到命令行中吧。

4.2 方法1

方法1是最直接簡單的方式，在命令行的結尾再給ld一次找該符號的機會。理論上，因爲已經知道符號就在該庫中定義，所以ld就能從新添加的這個選項中找到該標號。此法對於簡單的小規模程序很合適。

不過對於Makefile管理的大項目就不行了。因爲通常大項目會定義“LIBS”之類的變量。若LIBS變量插在鏈接命令行的中間位置，且 Makefile 中鏈接命令過多，在逐個命令最後添加新選項可是個易出錯、難維護的體力活。

4.3 方法2

這是最文雅的方式。用“ –start-group“ 和”–end-group”擴起來的 .a文件會被反覆解析，直到所有的符號都找到定義。因爲這些選項都是給鏈接器ld用的,所以加上了”-Wl,”,代表緊接的選項傳給鏈接器。默認情況下，ld會自動加上“–start-group -lgcc -lgcc_eh -lc –end-group”.意思是找不到的符號／函數名就在這幾個庫裏面使勁搜，因爲這幾個庫太底層了，符號間有依賴。

雖然這種方式能避免方法1中易出錯、難維護的體力活。不過因爲需要反覆的解析其中的庫文件，如果.a文件過多過大的時候，會增加鏈接時間。

4.4 方法3

這是最KISS的方法，簡單高效。既然多個.a文件間存在循環引用依賴，ld解決不了循環依賴關係。那麼我們可以參考從集羣、網格計算到雲計算的進化過程。把一坨.a揉成一個.a文件(ar命令可以實現此操作），交給ld。這樣循環依賴問題就解決了。

這種方式避免了ld反覆解析同一個.a文件，降低鏈接時間開銷。不過該方法比較適合項目開發時使用，因爲需要調整Makefile，而且將哪些.a揉成一個.a也是一個問題。比如我遇到的錯就是因爲pthread庫函數出現undefined reference，標準庫很多的時候也有點頭大。

5 參考

• http://stackoverflow.com/questions/45135/linker-order-gcc/409470#409470
• http://linux.die.net/man/1/ld
• http://stackoverflow.com/questions/45135/linker-order-gcc
• http://stackoverflow.com/questions/6045809/problem-with-g-and-undefined-reference-to-gxx-personality-v0
• http://linux.die.net/man/1/ar
• 程序員的自我修養–鏈接、裝載與庫。 俞甲子、石凡、潘愛民著

轉自：http://ticktick.blog.51cto.com/823160/431329

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

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

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

1.  鏈接時缺失了相關目標文件（.o）

    測試代碼如下：

 

    然後編譯。

gcc -c test.c
gcc –c main.c

    得到兩個 .o 文件，一個是 main.o，一個是 test.o ，然後我們鏈接 .o 得到可執行程序：

gcc -o main main.o 

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

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

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

gcc -o main main.o test.o

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

gcc -o main main.c //缺少test()的實現文件

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

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

2.    鏈接時缺少相關的庫文件（.a/.so）

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

    先把test.c編譯成靜態庫(.a)文件

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

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

gcc -c main.c

    這時，則生成了main.o文件，然後我們再通過如下命令進行鏈接希望得到可執行程序。

gcc -o main main.o

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

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

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

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

     【擴展】：同樣，爲了把問題說清楚，上面我們把代碼的編譯鏈接分開了，如果希望一次性生成可執行程序，則可以對main.c和test.a執行如下命令。

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文件。

gcc -c func.c
gcc -c test.c
gcc -c main.c

    然後，將test.c和func.c各自打包成爲靜態庫文件。

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

    這時，我們準備將main.o鏈接爲可執行程序，由於我們的main.c中包含了對test()的調用，因此，應該在鏈接時將test.a作爲我們的庫文件，鏈接命令如下。

gcc -o main main.o test.a

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

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

    就是說，鏈接的時候，發現我們的test.a調用了func()函數，找不到對應的實現。由此我們發現，原來我們還需要將test.a所引用到的庫文件也加進來才能成功鏈接，因此命令如下。

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

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

4 多個庫文件鏈接順序問題

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

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

    我們會得到如下報錯.

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

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

5. 在c++代碼中鏈接c語言的庫

    如果你的庫文件由c代碼生成的，則在c++代碼中鏈接庫中的函數時，也會碰到undefined reference的問題。下面舉例說明。

    首先，編寫c語言版庫文件： 

    

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

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

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

    

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

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

    會發現報錯：

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

    原因就是main.cpp爲c++代碼，調用了c語言庫的函數，因此鏈接的時候找不到，解決方法：即在main.cpp中，把與c語言庫test.a相關的頭文件包含添加一個extern "C"的聲明即可。例如，修改後的main.cpp如下：

    

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

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

6.  總 結

    當然，上面幾種是我目前發現的比較常見的undefined reference錯誤的原因和解決方法，可能也有其他各種原因，歡迎大家來信[email protected]交流，對本文檔進行補充，方面新手們解決學習過程中遇到的各種問題。