原文位址:http://blog.csdn.net/cserchen/article/details/5503556
Linux下編譯程式時,經常會遇到“undefined reference to XXX” 報錯,
這裡總結一些可能的原因和解決方案,給需要的朋友:
說道undefined reference error,先提一下Linux gcc連結規則:
連結的時候查找順序是:
-L 指定的路徑, 從左到右依次查找
由 環境變量 LIBRARY_PATH 指定的路徑,使用":"分割從左到右依次查找
/etc/ld.so.conf 指定的路徑順序
/lib 和 /usr/lib (64位下是/lib64和/usr/lib64)
動态庫調用的查找順序:
ld的-rpath參數指定的路徑, 這是寫死在代碼中的
ld腳本指定的路徑
LD_LIBRARY_PATH 指定的路徑
/etc/ld.so.conf 指定的路徑
/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錯誤的原因是:
0. 其實錯誤的名字很清楚了,就是沒有找到你調用的方法的定義代碼。從這裡入手,應該就由線索了。如果還是不能解決,請參考下面幾條。
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沒有把所有需要的庫都連結上,具體參加上文中對于靜态庫和動态庫混合使用的說明