linux - 加载程序时出现符号查找错误。 Symbol定义在静态库中，可以使用nm查看

Question

我在运行程序时看到以下错误:

/usr/bin/getinfo: symbol lookup error: /usr/pkl/libinfo.so: undefined symbol: GetList

此函数“GetList”在已链接到可执行文件 /usr/bin/getinfo 的静态库 liblist.a 中定义> 并用 gcc 编译。当我运行“nm”命令时，我可以看到可执行文件 getinfo 中定义了符号。这是 nm 命令的输出:

root@pkl $ nm /usr/bin/getinfo | grep GetList
080a3d89 T GetList

我还使用 readelf 命令进行了检查，这是输出:

root@pkl $ readelf -a /usr/bin/getinfo | grep GetList
 1080: 080a3d89 1777 FUNC   GLOBAL DEFAULT   15 GetList

libinfo.so 共享库调用定义在liblist.a 静态库中的函数GetList。 libinfo.so 和 liblist.a 都列为可执行文件 /usr/bin/getinfo 的依赖项。 liblist.a 未添加为 libinfo.so 的依赖项 我也做了 objdump -S/usr/bin/getinfo | grep GetList 可以看到这个函数的汇编代码。但是，在运行该程序时，它因符号查找错误而崩溃。这不是共享库问题，我无法解决。请帮忙。

Answer 1

好吧，您正在动态加载共享对象 /usr/pkl/libinfo.so 可能是通过使用 dlopen(3) 或类似函数。知道您如何编译 getinfo(确切的链接命令)以及如何加载共享库(如果它正在调用 dlopen(3) 或自动加载)会很有趣在程序启动时)链接过程后没有可用的静态库信息(因为静态库的链接仅包括从中提取 .o 文件并将它们正常链接到可执行文件)，所以说GetList 来自静态库或来自 *.o 对象在这里没有意义。

显示链接 getinfo 可执行文件的确切命令序列，如果您通过调用 dlopen(3) 加载 libinfo.so围绕通话的一些上下文也应该引起人们的兴趣。此外，知道 GetList 是 C 还是 C++ 函数应该很容易知道，因为 C++ 符号的名称被编译器破坏以应对参数列表类型匹配。也许您在 nm 的输出中看到了 C 风格的函数，但您正在尝试调用 C++ GetList 函数。

顺便说一下，在链接完成后，关于某些静态库的依赖信息是什么意思。我想 GetList 函数包含在可执行文件中，正如您在 nm(1) 输出中显示的那样。所以它应该在动态链接时对 libinfo.so 共享对象可用(这取决于链接过程中链接器的某些选项——这就是要求您提供确切链接命令的原因used) 如果可能的话，了解 libinfo.so 模块的确切链接命令也很重要。

编辑您的问题并添加缺失的信息，以便我们为您提供帮助。