對於我這個剛入IT行業不就得新手來說，在linux下連結庫的時候總是會遇到各種各樣奇葩的問題，最多的就是“undefined reference to”和“cannot find”這兩類，層出不窮，總是在我即將完成工作的時候給我當頭一棒，讓我欲罷不能。這不，這幾天編譯linux下一個專案時又遇到難題了。

        在我編譯的專案中，其中需要編譯一個靜態庫（下面命名為libA.a），而libA.a需要依賴另外兩個動態庫（下面命名為libB.so和libC.so），剛開始在編譯libA.a時，提示找不到libB.so和libC.so裡面的函式介面。然後看了一下Makefile，便發現了原因。這個不難。原來是我只在由.o檔案連線成.a檔案時有連結了libB.so和libC.so動態庫，但是在由.c編譯成.o時並沒有連結libB.so和libC.so。所以這一步直接提示找不到動態庫裡面的函式介面。按照上面的錯誤原因修改Makefile之後，便輕易地編譯成功了。

        就在我以為一切都大功告成的時候，我才發現我又高興的太早了。當我將編譯好的libA.a以及它所依賴的libB.so和libC.so都連線在專案中時（像我一樣的新手千萬別忘了，這個依賴的是動態庫，要連同一起連線在專案中，我就吃過虧），編譯出現的錯誤，錯誤內容還是“undefined reference to”libB.so和libC.so裡面的函式介面。我當時就蒙了，這是什麼情況，我明明都連結進去了啊，為什麼還是這樣。從錯誤的提示內容可以看出libA.a裡面的函式介面都正常，唯獨libB.so和libC.so他們兩個裡面的函式介面找不到。我就懷疑是不是沒有找到這兩個動態庫或者連結出錯之類的，折騰了一會我發現我又錯了，如果沒連結成功會有類似“cannot find”之類的提示。所以說鏈是連結上了，可為什麼還是找不到呢。就在我百思不得其解時，突然一個念頭從腦海中閃過“順序”，難道問題是出在我連線庫的順序上？當前的順序是先連線的libB.so和libC.so，然後再連結libA.a。於是我抱著一絲希望將libA.a調到了libB.so和libC.so兩個前面，先連線libA.a，執行make。。。真TM編過了。哎，看來真的是年輕啊。

        至於為什麼會這樣，在這就不多廢話了，有興趣的碼友可以專門去了解一下

=====================================================================================

Linux下編譯程式時，經常會遇到“undefined reference error” 報錯，這裡總結一些可能的原因和解決方案，給需要的朋友。

說到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錯誤的原因可能來自以下幾方面：

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沒有把所有需要的庫都連結上，具體參加上文中對於靜態庫和動態庫混合使用的說明。

原連結：http://www.2cto.com/os/201112/113315.html

===========================================================

lib/libQtGui.so: undefined reference to `ts_read_raw’

/lib/libQtGui.so: undefined reference to `ts_open’

/lib/libQtGui.so: undefined reference to `ts_fd’

/lib/libQtGui.so: undefined reference to `ts_config’

/lib/libQtGui.so: undefined reference to `ts_close’

/lib/libQtGui.so: undefined reference to `ts_read

解決辦法：

‘修改qt-everywhere-opensource-src-4.7.2/mkspecs/qws/linux-arm-g++/qmake.conf 檔案（新增lts引數）：

QMAKE_CC = arm-linux-gcc -lts

QMAKE_CXX = arm-linux-g++ -lts

QMAKE_LINK = arm-linux-g++ -lts

QMAKE_LINK_SHLIB = arm-linux-g++ -lts