獲取文件引起鏈接錯誤的G ++

我建立它使用被編譯爲.so文件的多個組件的二進制文件。我遇到了一系列鏈接器錯誤，指向哪個.so文件導致它們，但是我可以獲得有關哪些文件調用未定義函數的信息，或者如果可能的話源代碼位置中調用了未定義的函數？我發現尋找esp函數非常繁瑣，因爲大量的重載和模板正在被使用（這意味着在很多地方都有相同的名字）。在Windows中，它顯示了哪個.o文件導致了未定義的符號，但我堅持在Linux的庫級別。我在linux中使用g ++。任何指針都會有用。獲取文件引起鏈接錯誤的G ++

來源

2011-03-15 Venkatesan

爲什麼不跳過庫的步驟？不是將對象合併到庫中並動態加載它們，而是直接將對象鏈接到二進制文件中。 – Beta 2011-03-15 05:48:16

你問「哪些對象共享庫文件內導致錯誤」。

的問題是，通過共享庫已鏈接的時候，所有的目標文件已被「融合在一起」，而不再共享庫作爲獨立的實體存在於內部，所以你的問題是有點意思的。

這就是說，如果你做一個調試版本（與-g標誌），連接器將告訴你哪些源文件和行導致了問題，你的話也許能翻譯成目標文件。

如果你不能（例如，因爲這個問題符號在頭文件中引用的），你可以尋求幫助的鏈接：再次重建庫，通過鏈接-y標誌：

g++ -fPIC -shared ${OBJECTS} -o foo.so -Wl,-y,my_unresolved_symbol

會告訴你哪個對象參考my_unresolved_symbol。

注：連接器操作「低於」 C++，所以你必須通過重整名稱，例如_Znw。

來源

2011-03-16 04:44:24

感謝您的信息，它非常有用。我還設法調整了構建系統來生成靜態庫而不是動態庫，現在gcc提供了我想要的信息。 – Venkatesan 2011-03-18 08:14:04

隨着ldd（打印共享庫的依賴），你可以檢查的依賴所以，如果他們解決與否。

通過使用nm -Aa --demangle，您可以獲取* .so文件中使用或定義的符號列表，只要它們沒有被剝離。使用的符號至少應該保留，以便您可以檢查是否有一些未解決的符號。

來源

2011-03-15 05:46:44 jdehaan

謝謝，但我已經從錯誤消息中知道哪個文件導致錯誤。我想知道里面的哪個目標文件使用未定義的函數 – Venkatesan 2011-03-15 06:46:28

獲取文件引起鏈接錯誤的G ++

回答

相關問題