readelf -d 是唯一可靠方式，因 ldd 受 LD_LIBRARY_PATH、RPATH 等环境干扰，且不校验 libc++ 依赖库（如 libcxxabi.so.1）的 ABI 兼容性，易致部署时报 cannot open shared object file。
libc++ 项目发布前必须用 readelf -d 查 ELF 的真实 NEEDED 条目，不能只信 ldd —— 后者受环境变量干扰，上线后容易“明明本地能跑，部署就报 cannot open shared object file”。
为什么 ldd 在 libc++ 场景下特别不可靠
libc++ 是 LLVM 的 C++ 标准库实现，它默认不依赖 libstdc++.so，但可能显式链接 libcxxabi.so、libunwind.so 或系统 libc.so.6。而 ldd 会顺着当前 LD_LIBRARY_PATH、RPATH 甚至 runpath 去找库，导致两种典型误判：
- 本地
LD_LIBRARY_PATH=/usr/local/lib下ldd myapp显示libcxxabi.so.1 => /usr/local/lib/libcxxabi.so.1，但目标机没这个路径，直接挂 - 你编译时用了
-Wl,-rpath,$ORIGIN/../lib，ldd能找到，但$ORIGIN在容器或非标准目录下不生效 -
ldd对libc++自身的 ABI 依赖（如libcxxabi.so.1）不做版本兼容性校验，只管“能不能加载”，不查符号是否匹配
用 readelf -d 看 libc++ 二进制的真实依赖
这是唯一能绕过环境干扰、看到 ELF 文件“声明要什么”的方式。对 libc++.so.1 或使用它的可执行文件都适用：
- 运行：
readelf -d libc++.so.1 | grep NEEDED - 输出中每行
(NEEDED) Shared library: [xxx]就是硬编码进二进制的依赖名（即 soname） - 重点关注是否出现
libcxxabi.so.1、libunwind.so.1、libc.so.6—— 这些必须在目标系统存在且 soname 匹配 - 若输出里有
[libstdc++.so.6]，说明你意外链接了 GCC 的标准库（比如混用了-stdlib=libstdc++），和 libc++ 定位冲突
检查 libc++ 是否被正确静态链接或隔离
libc++ 项目常希望避免运行时依赖第三方 ABI 库（尤其是 libcxxabi）。这时要确认链接行为：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 编译时加
-DLIBCXXABI_ENABLE_STATIC_UNWIND=ON并链接libcxxabi.a，可消除libunwind.so依赖 - 用
nm -D libc++.so.1 | grep __cxa查看是否导出 ABI 符号；如果大量__cxa_*符号存在，说明仍需libcxxabi.so - 若想彻底静态化，可用
clang++ -stdlib=libc++ -static-libc++，此时readelf -d输出应不含任何libc++*相关 NEEDED 条目 - 注意：静态链接
libc++不等于静态链接libc；libc.so.6仍会出现在 NEEDED 中，这是正常且必需的
发布包里必须验证的三件事
光看依赖不够，得确保部署时能真正加载：
- 把
libc++.so.1和它依赖的libcxxabi.so.1（如有）一起打进发布包，并放在同一级目录 - 用
objdump -p myapp | grep RUNPATH确认RUNPATH设置为$ORIGIN/../lib或相对路径，而非绝对路径 - 在目标环境（最小化 Docker 镜像或干净 VM）中清空
LD_LIBRARY_PATH后运行：LD_LIBRARY_PATH= ldd ./myapp—— 这才是最接近真实部署的测试
最容易被忽略的是 libcxxabi.so 的 soname 版本号是否与 libc++.so 编译时绑定的一致；不同 LLVM 版本生成的 libcxxabi.so.1 可能 ABI 不兼容，仅文件名相同也不行。
