“程序在开发机正常，部署到服务器就找不到库”通常不是单一的环境变量问题。ELF 动态链接同时涉及可执行文件请求的 SONAME、运行时的搜索规则、库的 ABI、符号版本和进程环境。排查时先画出加载链，再决定是否需要改变配置。
本文是历史共享库和动态链接笔记的重组稿。不同发行版、加载器和工具链的细节可能不同，示例命令应在目标环境验证。
先区分四类问题
| 现象 | 优先怀疑 |
|---|---|
error while loading shared libraries |
库缺失、搜索路径或架构不匹配 |
| 启动时符号冲突 | SONAME/版本、全局符号、依赖顺序 |
| 前台正常、后台失败 | 工作目录、环境变量、服务权限或 namespace |
| 换机器后崩溃 | glibc、libstdc++、CPU 指令集或 ABI 不一致 |
先收集证据，不要先写 export LD_LIBRARY_PATH=/...。全局路径可能让错误暂时消失，却把不兼容的库注入所有进程。
1. 确认文件身份
file ./your-program
readelf -h ./your-program | grep 'Class'
readelf -d ./your-program | grep NEEDED
readelf -d ./your-program | grep -E 'RPATH|RUNPATH|NEEDED'
file 用于确认架构和文件类型，readelf 查看动态段。对于共享库，还要检查 SONAME、需要的库版本和符号版本：
readelf -d ./libyour.so | grep SONAME
readelf --dyn-syms ./libyour.so | grep 'symbol_name'
不要把 ldd 当成未知文件的绝对安全检查器；对不可信二进制，优先使用 file、readelf -d 和 objdump -p。历史 ldd/ldconfig/LD_LIBRARY_PATH 记录可作为概念参考。
2. 理解搜索规则的层次
可以把动态加载过程简化为：
DT_RPATH / DT_RUNPATH（取决于具体规则）
→ LD_LIBRARY_PATH
→ /etc/ld.so.cache（ldconfig 管理）
→ 默认系统目录
→ 部分平台的可执行器特定规则
实际顺序受动态链接器、ELF 标记、ld.so 配置和安全策略影响。不要只背一条“固定顺序”；应在目标机器上用 LD_DEBUG=libs,files 做一次受控实验，并保存结果。
- RPATH/RUNPATH：由 ELF 携带，适合表达受控的相对安装布局，但要注意优先级和安全影响。
- LD_LIBRARY_PATH：适合临时诊断和隔离环境，不宜成为未审计的全局生产配置。
- ldconfig：更新系统共享库缓存，不等于把所有第三方库复制进系统目录。
- 系统目录：发行版管理的 ABI 应优先由包管理器提供，不应被项目私自覆盖。
3. SONAME、文件名和版本
构建系统、安装规则和运行时必须对同一个库的“身份”达成一致。一个库可以有：
文件名：libfoo.so.1
SONAME：libfoo.so.1
开发链接名：libfoo.so
升级 ABI 时，文件名和 SONAME 是否变化应与兼容性策略绑定。不要只把文件复制成新名字就认为升级完成；下游程序仍然按照 ELF 中的 NEEDED 名称寻找它。
CMake SONAME 记录 和 共享库基础 适合补充构建侧知识；部署侧还要检查最终安装目录、运行时权限和容器挂载。
4. 前后台差异的排查
进程从终端启动改为 systemd、容器或后台服务后，常见变化包括：
- 当前工作目录不同；
PATH、LD_LIBRARY_PATH、locale 和 HOME 不同；- 用户、umask、挂载 namespace 不同；
- shell 启动脚本设置了交互式环境；
- 服务清理了环境或使用了安全沙箱。
用最小服务复现，并记录 /proc/<pid>/environ（仅在有权限且不含敏感值的测试环境中）、/proc/<pid>/maps、实际工作目录和加载器日志。不要把包含密钥的完整环境输出贴到公开 issue。
5. 符号冲突与 C++ ABI
当两个库导出同名 C++ 符号，进程可能加载了错误实现，尤其在没有正确符号版本或隐藏可见性时。排查顺序：
- 用
readelf --dyn-syms确认导出符号； - 检查链接顺序和
NEEDED； - 查看库的 SONAME 和构建选项；
- 检查是否混用了不同 C++ ABI、编译器和运行库；
- 逐步去掉非必要依赖，验证最小组合。
全局函数重名与命名空间记录 说明了这类问题的表现，但生产修复应优先采用清晰的库边界、版本化 SONAME 和正确的作用域，而不是依赖全局隐藏。
部署检查清单
目标架构：
glibc / libstdc++ 版本：
可执行文件 NEEDED：
每个库的 SONAME 与实际路径：
RPATH/RUNPATH：
环境变量来源：
服务用户与 namespace：
符号冲突检查：
干净机器安装测试：
回滚包：
先解决“哪一个库被加载、为什么被选中”，再决定是否修改 loader 配置。这样才能把共享库部署从试错变成可验证的工程过程。