鏈接器告訴我它不能解析符號，但它們在那裏？

我想編寫一個簡單的測試應用程序，使用我寫的庫。這在其他機器上編譯並運行良好。鏈接器告訴我它不能解析符號，但它們在那裏？

我有libroller.so可在/ usr/lib。我編譯main.cpp中這樣：

g++ -g3 -Wall -I"../../" -lrt -lroller -o rap main.o

它抱怨許多錯誤，如：

/....../main.cpp:51: undefined reference to `Log::i(char const*, ...)'

但是，我知道，這些在此所以存在：

nm -Ca /usr/lib/libroller.so | grep "Log::i"    
00000000001f5d50 T Log::i(char const*, ...) 
0000000000149530 W Log::i(std::string const&)

兩者都是64位：

file /usr/lib/libroller.so   
/usr/lib/libroller.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped 

file main.o 
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

UNL ike GCC and ld can't find exported symbols...but they're there!我很確定這些符號是被定義的。同樣的.so與另一個使用一些相同的符號。

編輯/回答：對象的順序很重要。在庫之前放置main.o是必要的。我猜連接器沒有未解決的符號來處理，直到它到達main.o - 哪個是其列表中的最後一個對象。我仍然對爲什麼這個工作在其他機器上許多個月有點糊塗了......

來源

2011-12-05 notlesh

你的問題是[this one] [1]的重複，並有相同的答案。 [1]：http://stackoverflow.com/questions/8380087/boost-1-48-linking-issue-with-gcc-4-6-1 –

感謝。我做了搜索，我保證:)搜索「未解決」和「gcc」會出現大量不相關的答案... – notlesh

[爲什麼庫鏈接的順序有時會導致GCC錯誤？]（https： //stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc） –

變化：

g++ -g3 -Wall -I"../../" -lrt -lroller -o rap main.o

到：

g++ -g3 -Wall main.o -lroller -lrt -o rap

鏈接順序問題（和-I在這種情況下是多餘的）。

來源

2011-12-05 07:35:05

考慮更改庫和main.o的序列：

g++ -g3 -Wall -I"../../" -o rap main.o -lrt -lroller

看一看這個帖子：Why does the order in which libraries are linked sometimes cause errors in GCC?

來源

2011-12-05 07:35:10

你的問題的this one一個DUP，並具有相同的答案：鏈接線路上的庫的順序matters。

來源

2011-12-05 07:35:53

鏈接器告訴我它不能解析符號，但它們在那裏？

回答

相關問題