是否有任何工具可以检查交叉编译的 .so 文件中的符号？答案

【问题标题】：Are there any tools for checking symbols in cross compiled .so files?是否有任何工具可以检查交叉编译的 .so 文件中的符号？
【发布时间】：2010-09-21 04:47:38
【问题描述】：

我有一个应用程序在启动时将 .so 文件作为插件加载，使用 dlopen()

构建环境在 x86 硬件上运行，但正在为另一个平台交叉编译应用程序。

如果我可以（作为自动构建过程的一部分）进行检查以确保 .so 文件和应用程序的组合中没有任何未解析的符号，而无需实际部署，那就太好了应用程序。

在我编写脚本来使用nm 的输出测试符号之前，我想知道是否有人知道已经这样做的实用程序？

编辑 1：稍微更改了描述 - 我不只是尝试测试 .so 中的符号，而是尝试结合几个 .so 和应用程序本身 - 即。在应用程序加载完所有的.so之后是否还有未解析的符号。

正如答案中所建议的那样（感谢 Martin v. Löwis 和 tgamblin），nm 将很容易识别单个文件中缺少的符号，但不容易识别其中哪些符号已在另一个加载的文件中得到解决模块。

【问题讨论】：

也许您可以为此使用递归 ldd。我将其添加到下面的答案中。

标签： linux cross-platform shared-libraries testing symbols

【解决方案1】：

nm 中的限制结果表明它无法用于全面的符号检查器。特别是，nm 只会列出导出的符号。

但是，readelf 将生成一个完整的列表以及所有库依赖项。

使用readelf 可以构建一个脚本：创建所有使用的库的列表，在可执行文件（或 .so）中建立符号列表建立一个未解析符号列表 - 如果此时有任何未解析符号，则在加载时会出错。

然后重复此操作，直到找不到新库为止。

如果对可执行文件和所有dlopen()ed .so 文件执行此操作，它将很好地检查运行时遇到的未解决依赖项。

【讨论】：

【解决方案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.

如果您要进行链接后检查，我同意 Martin 的观点，即 nm 可能是您最好的选择。我通常只是在输出中用 grep 搜索“U”来检查未解析的符号，所以我认为这将是一个非常简单的脚本。

【讨论】：

【解决方案3】：

理想情况下，跨纳米工具是您的交叉编译器套件的一部分。例如，如果您构建 GNU binutils 用于交叉编译，则还将提供一个 cross-nm（以及一个 cross-objdump）。

【讨论】：