当你在正常工作的系统里需要定位某个符号的具体来源库时，下面这些工具和步骤能帮你快速搞定，进而解决另一个系统的未解析符号问题：

1. 先缩小排查范围：查看目标库的依赖链 #

首先用ldd列出正常系统中那个能正常工作的共享库的所有依赖，这样你不用盲目遍历系统里所有的.so文件：

ldd /path/to/your/working_lib.so

输出里的第三列就是依赖库的绝对路径，把这些路径记下来，接下来只需要在这些库里找符号就好，效率高很多。

2. 用nm工具查找符号 #

nm是查看目标文件符号表的经典工具，加上-D参数可以只显示动态符号（也就是动态链接时会用到的符号）：

# 针对单个依赖库查符号
nm -D /path/to/dependency_lib.so | grep -w "your_target_symbol"

# 批量检查所有依赖库的循环脚本
for lib in $(ldd /path/to/your/working_lib.so | awk '{print $3}' | grep -v "not found"); do
    nm -D "$lib" 2>/dev/null | grep -w "your_target_symbol" && echo "Found in: $lib"
done

-w参数确保匹配完整的符号名，避免部分匹配导致的干扰；2>/dev/null用来屏蔽那些无法读取的库的错误信息。

3. 用objdump验证符号 #

objdump的-T参数也能显示动态符号表，输出格式和nm略有不同，有时候能提供额外的上下文（比如符号的类型、绑定属性）：

objdump -T /path/to/dependency_lib.so | grep -w "your_target_symbol"

4. 用readelf查看更详细的符号信息 #

readelf是专门针对ELF格式文件的工具，输出的信息更结构化：

# 查看动态符号表（-W避免换行，方便grep匹配）
readelf -sW /path/to/dependency_lib.so | grep -w "your_target_symbol"

如果想确认库的动态依赖关系，还可以用readelf -d /path/to/your/working_lib.so查看。

5. 动态追踪符号解析过程：LD_DEBUG环境变量 #

如果上面的静态查找没找到，或者你想亲眼看到符号是怎么被动态加载器解析的，可以用LD_DEBUG环境变量。比如运行依赖该库的Python程序：

LD_DEBUG=symbols python -c "import your_native_module"

输出会非常详细，你可以搜索目标符号，找到类似这样的行：

1234:     symbol=your_target_symbol;  lookup in file=/path/to/libfoo.so [0]
     1234:     binding file=/path/to/your/working_lib.so [0] to /path/to/libfoo.so [0]: normal symbol `your_target_symbol'

这直接告诉你符号是从libfoo.so里解析来的。

最后验证和解决问题 #

找到符号对应的库之后，你需要：

• 在有问题的系统里检查这个库是否存在，版本是否和正常系统兼容
• 确保问题系统的动态链接器能找到这个库（可以通过LD_LIBRARY_PATH临时添加路径，或者修改/etc/ld.so.conf并运行ldconfig）
• 如果库存在但还是解析失败，可能是符号的版本不匹配，或者库的ABI有变化，这时候需要对比两个系统里该库的符号表差异

内容的提问来源于stack exchange，提问作者schmittlauch