ldd命令能查看运行时实际加载的动态库路径，但结果受LD_LIBRARY_PATH等环境变量影响可能失真；更可靠的方式是用readelf -d binary | grep NEEDED直接读取ELF中声明的NEEDED依赖，不受环境干扰。
ldd 命令能直接看到运行时依赖，但结果可能被欺骗
ldd 是最常用的工具，它模拟动态链接器行为，列出可执行文件或 .so 文件实际会加载的库路径。但要注意：它在当前 shell 环境下运行，会受 LD_LIBRARY_PATH 和 RPATH 影响，有时显示“找到”，其实只是因为临时设置了路径——上线环境未必有。
常见错误现象：ldd myapp 显示所有库都 OK，但部署后报 error while loading shared libraries: libxxx.so: cannot open shared object file。
- 先清空干扰：
LD_LIBRARY_PATH= ldd myapp（等价于临时禁用该变量） - 对动态库本身也适用：
ldd libmycore.so - 若某行末尾出现
not found，说明系统找不到该库，不是版本问题，是根本缺失
readelf -d 能看到 ELF 的真实 NEEDED 条目，不含环境干扰
readelf -d 直接读取二进制文件的动态段，输出所有声明的依赖库名（如 libz.so.1），不经过链接器解析，也不查路径。它告诉你“程序声称需要什么”，而不是“现在能找到什么”。
使用场景：排查为什么 ldd 显示 not found，但你知道库明明存在——可能是名字不匹配（比如程序要 libfoo.so.2，而你只装了 libfoo.so.3）。
- 关键命令：
readelf -d myapp | grep NEEDED - 输出示例：
0x0000000000000001 (NEEDED) Shared library: [libm.so.6] - 注意：这里显示的是 soname，不是文件名；
libm.so.6是符号链接指向具体版本文件
objdump -p 作用类似 readelf，但输出格式略有不同
objdump -p 也提取程序头中的动态信息，和 readelf -d 输出内容高度重合，但字段命名和排版更贴近传统 Unix 工具习惯。部分老版本系统上 readelf 不可用时，可用它替代。
参数差异：objdump -p 默认输出全部程序头，必须配合 grep NEEDED 过滤；readelf -d 可直接加 --dynamic 选项聚焦。
- 等效命令：
objdump -p myapp | grep NEEDED - 性能影响：两者都是静态分析，毫秒级，无运行时开销
- 兼容性：CentOS 7+、Debian 10+、Ubuntu 18.04+ 均自带，无需额外安装
gcc -v 编译时看链接器调用，适合查构建期依赖来源
gcc -v 不用于检查已生成的二进制，而是帮你确认编译阶段链接器（ld）到底传了哪些 -lxxx 和 -L/path。这对定位“为什么最终二进制里没带上某库”很关键。
容易踩的坑：很多人以为 gcc -v 能看出运行时依赖，其实它只反映链接命令行——如果用了 -static-libgcc 或某些库被优化掉了，ldd 结果和 gcc -v 输出可能不一致。
- 典型用法：
gcc -v -o app main.c -lm -ldl - 重点看最后几行以
collect2或ld开头的命令，里面包含所有NEEDED库的原始指定形式 - 若想确认是否嵌入了
RPATH，搜输出里的-rpath或--rpath
ldd 的“绿色输出”。readelf -d 才暴露程序真正声明要什么，而 LD_LIBRARY_PATH= ldd 才反映裸环境下的加载能力——这两者不一致，就是线上出问题的伏笔。 
