undefined symbol错误发生在运行时而非编译期，表明程序可执行但动态链接器找不到符号定义；需用ldd -r定位缺失符号，readelf查RPATH，nm -D验证符号导出，结合c++filt解析C++修饰名，并检查ABI兼容性、链接顺序及extern "C"声明。
运行时报 undefined symbol，不是编译失败
这说明程序能编译通过、生成可执行文件，但运行时动态链接器找不到某个符号定义——比如函数或全局变量。它和 undefined reference（链接阶段报错）是两类问题，排查路径完全不同。
先用 ldd -r ./your_program 看输出里带 undefined symbol 的行，确认具体是哪个符号缺失；再用 readelf -d ./your_program | grep RPATH 查看程序是否硬编码了库搜索路径，避免被误导去查系统默认路径。
- 如果符号名是 C++ 风格（如
_ZNSt6chrono3steady10steady_clock3nowEv），大概率是 ABI 不兼容，不是缺库 - 如果符号名是 C 风格（如
pthread_create），优先检查依赖库是否真在运行环境里 -
LD_LIBRARY_PATH设置后仍不生效，可能是程序启用了 secure-execution 模式（如 setuid），此时该变量会被忽略
nm -D 显示符号为 U，说明动态库本身没导出
运行 nm -D libxxx.so | grep your_symbol，若结果是 U your_symbol（U 表示 undefined），说明这个库自己依赖别人，但它没把依赖的符号拉进来——它不是“最终提供者”。
比如 libfoo.so 用到了 libbar.so 的 bar_init，但编译 libfoo.so 时没加 -lbar，那 libfoo.so 就只存了个未解析引用，运行时自然崩。
- 修复方式：重新编译该动态库，确保所有它用到的符号，在链接命令里都显式带上对应
-l - 验证方法：
objdump -p libfoo.so | grep NEEDED，确认输出里包含libbar.so - 注意：不能靠主程序链接时补
-lbar来救，除非主程序直接调用了bar_init
gcc -l 参数顺序导致符号未解析
链接命令写成 gcc main.o -la -lb，而 liba.so 内部调用了 libb.so 的函数，就会失败。因为 GNU ld 是从左到右单次扫描，liba.so 里的未定义符号只回溯左边已处理的库，libb.so 在右边，被跳过。
- 正确写法：依赖者放右边，即
gcc main.o -lb -la - 更稳妥做法：用
--no-as-needed关掉默认裁剪（尤其涉及-shared或 PIE 构建时） - 静态库更敏感：
liba.a里引用了libb.a的符号，必须写成gcc main.o -la -lb，且两个都要是静态库
C++ 名称修饰导致符号对不上
头文件里声明了 void log_msg(const char*)，C++ 编译后变成类似 _Z7log_msgPKc；但如果用 C 代码调用，链接器找的是裸名 log_msg，必然失败。
典型场景：Python 扩展模块用 C++ 实现，但导出函数没加 extern "C"；或者 C 项目链接 C++ 库时漏了这一层封装。
- 修复：在 C++ 头文件中用
extern "C"包裹导出函数声明 - 验证：用
c++filt _Z7log_msgPKc看能否还原成原函数名；用nm -D your_lib.so | grep log_msg确认符号是否以 C 风格存在 - 注意：
extern "C"只影响链接符号名，不影响函数内部实现逻辑
真正麻烦的不是找不到库，而是符号看似存在却因 ABI、RPATH、名称修饰或链接顺序被静默忽略。动手前先用 ldd -r 和 nm -D 锁定符号层级，比盲目改 LD_LIBRARY_PATH 有效得多。
