因为symbol lookup error发生在程序运行时的动态链接阶段，此时动态链接器ld.so尝试解析已加载共享库中的符号但失败，而编译和静态链接阶段无法检测该问题。
为什么 symbol lookup error 不是编译期报错，而是运行时才崩？
因为这个错误发生在动态链接阶段：可执行文件启动后，ld.so 尝试从已加载的共享库中查找某个符号（比如函数或全局变量），但没找到。它和编译、链接时的 undefined reference 完全不同——后者能提前暴露问题，而这个错误会躲过所有构建检查，直到你真正运行程序。
常见诱因包括：
- 库版本不匹配（新程序依赖旧库里没有的符号）
-
dlopen()加载顺序错乱，导致先加载了不含目标符号的库 - 符号被
visibility=hidden或static修饰，未导出 -
libfoo.so和libfoo.so.1同时存在但软链接指向错误版本
用 ldd -r 和 nm -D 快速定位缺失符号
先确认报错里具体是哪个符号找不到，错误信息形如：./a.out: symbol lookup error: ./a.out: undefined symbol: foo_bar_init。拿到 foo_bar_init 这个名字后：
- 运行
ldd -r ./a.out，看输出里是否有类似undefined symbol: foo_bar_init的行，并注意它标注的所属库（比如libbar.so） - 然后查该库是否真含这个符号：
nm -D /path/to/libbar.so | grep foo_bar_init - 如果没输出，说明符号确实不在该库中；如果输出带
U（undefined），说明它又依赖别的库提供该符号
注意：nm -D 只显示动态导出符号，别用 nm 默认模式（它查静态符号）；如果库用了 -fvisibility=hidden，必须确保目标函数加了 <strong>attribute</strong>((visibility("default"))) 才会被 nm -D 看见。
立即学习“C++免费学习笔记（深入）”；
LD_DEBUG=bindings,symbols 看清符号绑定全过程
这是最直接的诊断方式，尤其适合多版本库共存或 RTLD_GLOBAL/RTLD_LOCAL 混用的场景：
- 运行
LD_DEBUG=bindings,symbols ./a.out 2>&1 | grep foo_bar_init - 观察输出中是否出现
binding file ... to /path/to/libbar.so [0]，以及后续有没有symbol not found或weak binding提示 - 关键看
[0]后面的数字是否对应正确的库加载序号；如果绑到了libbar.so.0而不是你期望的libbar.so.1，就说明SONAME或DT_RUNPATH设置有问题
容易忽略的一点：LD_DEBUG 输出极长，建议配合 grep -A5 -B5 查上下文，否则会错过关键绑定路径。
检查 SONAME、RPATH 和 runpath 是否一致
动态链接器靠这些元数据决定“去哪找、用哪个版本”的库：
- 查
SONAME：readelf -d libbar.so | grep SONAME，应为libbar.so.1这类带主版本号的名字 - 查可执行文件用什么路径找库：
readelf -d ./a.out | grep -E "(RPATH|RUNPATH)" - 如果输出是
RPATH，它优先级高于环境变量LD_LIBRARY_PATH；如果是RUNPATH，则优先级更低 - 若
RPATH写死成/opt/old/lib，但新库装在/usr/local/lib，就会加载旧版并缺符号
修复建议：
- 编译时用
-Wl,-rpath,'$ORIGIN/../lib'替代绝对路径，让可执行文件相对自身位置找库 - 避免用
patchelf临时改RPATH——这容易掩盖构建配置缺陷
符号导出和运行时解析之间的缝隙很窄，但一旦出问题，现象高度相似、原因却可能横跨编译选项、链接脚本、安装路径、加载顺序多个层面。盯住那个报错的符号名，一层层反向验证它“该在哪”“真在哪”“被谁绑”，比重编一遍更省时间。
