加载程序时符号查找错误。符号在静态库中定义，可以使用nm查看答案

【问题标题】：Symbol lookup error when loading a program. Symbol is defined in static library and can be seen using nm加载程序时符号查找错误。符号在静态库中定义，可以使用nm查看
【发布时间】：2017-07-07 11:38:32
【问题描述】：

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

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

这个函数'GetList'在静态库liblist.a中定义，该库已链接到可执行文件/usr/bin/getinfo并使用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 并且可以看到这个函数的汇编代码。但是，在运行程序时，它会因符号查找错误而崩溃。这不是共享库问题，我无法解决。请帮忙。

【问题讨论】：

标签： linux runtime loader symbols

【解决方案1】：

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

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

顺便说一句，在链接完成后，关于某些静态库的依赖信息是什么意思。我想GetList 函数包含在可执行文件中，正如您在nm(1) 输出中显示的那样。因此，在动态链接时，libinfo.so 共享对象应该可以使用它（这取决于链接过程中链接器的某些选项 --- 这就是询问您使用的确切链接命令的原因）同样重要的是如果可能，知道libinfo.so 模块的确切链接命令。

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

【讨论】：