是否有任何工具可用於檢查交叉編譯的.so文件中的符號？

Question

我有一個應用程序，在啓動時將.so文件加載爲插件，使用dlopen()

構建環境在x86硬件上運行，但應用程序正在針對另一個平臺進行交叉編譯。

如果我可以（作爲自動化構建過程的一部分）執行檢查以確保在.so文件和應用程序的組合中沒有任何未解決的符號，而無需實際部署應用程序。

在我編寫腳本測試符號使用輸出nm之前，我想知道是否有人知道已經這樣做的實用程序？

---

編輯1：略有變化的說明 - 我不只是想在。所以測試的符號，而是幾個。所以公司和應用程序本身的結合 - 即。在應用程序加載所有的.so之後，是否仍然存在未解析的符號。

正如答案中所建議的（感謝Martin v。Löwis和tgamblin），nm可以輕鬆識別單個文件中缺失的符號，但不容易識別哪些符號已在其他已加載模塊之一中解決。

Answer 1

理想情況下，交叉nm工具是交叉編譯器套件的一部分。例如，如果您爲交叉編譯構建GNU binutils，則還會提供交叉nm（以及cross-objdump）。

Answer 2

你可以使用ldd的遞歸版本嗎？有人似乎有written a script可能會有所幫助。這至少告訴你，所有的依賴庫都可以解決，如果它們在.so中正確指定的話。你可以保證所有的依賴都在.so中用鏈接器選項引用，而這個遞歸的ldd會保證你沒有未解決的符號。

鏈接器通常會有一個選項，使共享庫中未解析的符號出現錯誤，您可以使用它來避免必須檢查。對於GNU ld，你可以傳遞--no-allow-shlib-undefined，並且保證如果它產生.so，它不會有未解析的符號。從GNU LD文檔：

--no-undefined 
     Report unresolved symbol references from regular object files. 
     This is done even if the linker is creating a non-symbolic shared 
     library. The switch --[no-]allow-shlib-undefined controls the 
     behaviour for reporting unresolved references found in shared 
     libraries being linked in. 

    --allow-shlib-undefined 
    --no-allow-shlib-undefined 
     Allows (the default) or disallows undefined symbols in shared 
     libraries. This switch is similar to --no-undefined except 
     that it determines the behaviour when the undefined symbols are 
     in a shared library rather than a regular object file. It does 
     not affect how undefined symbols in regular object files are 
     handled. 

     The reason that --allow-shlib-undefined is the default is that the 
     shared library being specified at link time may not be the 
     same as the one that is available at load time, so the symbols might 
     actually be resolvable at load time. Plus there are some systems, 
     (eg BeOS) where undefined symbols in shared libraries is normal. 
     (The kernel patches them at load time to select which function is most 
     appropriate for the current architecture. This is used for example to 
     dynamically select an appropriate memset function). Apparently it is 
     also normal for HPPA shared libraries to have undefined symbols. 

如果你打算去一個鏈接後檢查，我與馬丁認爲，納米可能是你最好的選擇。我通常只是在輸出中尋找'U'來檢查未解決的符號，所以我認爲這將是一個非常簡單的腳本來編寫。

Answer 3

nm中的限制原來意味着它不可能用於全面的符號檢查器。 特別是，nm只會列出導出的符號。

但是，readelf將生成一個綜合列表以及所有的庫依賴關係。

使用readelf有可能建立一個腳本，將： 創建所有使用的庫的列表， 樹立符號列表中的可執行文件（或.so） 樹立懸而未決列表符號 - 如果此時有任何未解決的符號，則加載時會出現錯誤。

然後重複此操作，直到找不到新的庫。

如果對可執行文件和所有dlopen() ed .so文件執行此操作，它將很好地檢查運行時可能遇到的未解決的依賴關係。