LD_LIBRARY_PATH指定的libQt5Core.so.5被跳过，如何排查原因？

这种情况我之前踩过好几次坑，libQt5Core.so.5作为Qt的核心库，经常因为一些容易被忽略的细节被动态链接器直接跳过。给你列几个优先级最高的排查方向，一步步来定位问题：

1. 先检查库的基础兼容性与依赖链 #

• 用readelf -d ./your-custom-lib-dir/libQt5Core.so.5 | grep NEEDED查看它依赖的系统基础库（比如glibc、libpthread等），重点对比运行环境的对应库版本。如果你的Qt库是用更高版本的glibc编译的，而部署机器的glibc版本偏低，ld会判定这个库无法兼容，直接跳过。
• 再执行ldd ./your-custom-lib-dir/libQt5Core.so.5，检查是否有缺失的依赖项——哪怕是一个不起眼的辅助库（比如libicui18n.so.68这类）找不到，动态链接器都会直接放弃这个自定义库，转而加载系统版本。

2. 验证符号版本匹配度 #

libQt5Core.so.5有严格的符号版本要求（比如Qt_5、Qt_5.15、Qt_5.15.2等），如果程序需要的符号版本在你的自定义库里找不到，ld会自动跳过它：

• 用objdump -T ./app.bin | grep Qt_提取你的程序依赖的Qt符号版本；
• 再用objdump -T ./your-custom-lib-dir/libQt5Core.so.5 | grep Qt_对比，看看是否存在程序需要但自定义库没有的符号版本。另外，系统库的符号版本可能更全，ld会优先选择能满足所有符号需求的库。

3. 确认LD_LIBRARY_PATH的优先级与生效性 #

• 先检查LD_LIBRARY_PATH的设置顺序：执行echo $LD_LIBRARY_PATH，确保你的自定义库目录排在系统库路径（比如/usr/lib64、/lib64）前面。如果系统路径在前，ld可能先找到系统库就直接使用了。
• 注意LD_LIBRARY_PATH的生效范围：如果是临时设置，必须在启动程序的同一个Shell中执行（比如用export LD_LIBRARY_PATH=/path/to/your/libs:$LD_LIBRARY_PATH && ./app.bin的方式启动），否则设置不会生效。

4. 深入分析LD_DEBUG的输出细节 #

你已经用到了LD_DEBUG=all，可以针对性过滤输出，更容易定位问题：

• 执行LD_DEBUG=libs ./app.bin 2>&1 | grep libQt5Core，重点找类似version mismatch（版本不匹配）、missing symbol（缺失符号）、rejected（被拒绝）的关键词，这些会直接告诉你ld跳过自定义库的原因。
• 如果看到file=libQt5Core.so.5 [0]; 无法加载这类日志，结合前面的依赖检查，基本就能锁定问题。

5. 检查库的权限与SELinux限制 #

• 确认自定义库的权限：执行ls -l ./your-custom-lib-dir/libQt5Core.so.5，确保当前用户有读权限（至少有r标识），没有权限的话ld无法读取库文件。
• 排查SELinux影响：如果是Linux系统，执行getenforce查看是否处于Enforcing模式。如果是，临时执行setenforce 0关闭SELinux后再启动程序测试——如果能正常加载，说明是SELinux阻止了非标准路径的库加载，后续需要配置SELinux规则允许该目录的库被加载。

6. 验证库文件的完整性 #

有时候拷贝过程中库文件可能损坏，导致ld无法识别：

• 用md5sum对比编译机器上的原libQt5Core.so.5和部署机器上的库文件，确认哈希值一致；
• 执行readelf -h ./your-custom-lib-dir/libQt5Core.so.5检查ELF头是否正常，没有损坏的标识。

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