ldd不能可靠显示全部依赖，因其会实际加载程序触发入口点执行、受环境变量干扰且忽略部分elf声明条目；真正安全完整的方式是readelf -d binary | grep needed，直接解析elf动态段中硬编码的dt_needed条目。
ldd 能快速列出运行时实际解析到的动态库路径，但它不是“查看全部依赖”的安全或完整方案——它会加载程序、受环境干扰、且对不可信二进制有执行风险。
为什么 ldd 不能可靠显示“全部”依赖
ldd 的本质是设置 LD_TRACE_LOADED_OBJECTS=1 后调用目标程序自身，因此：
- 它会触发程序的入口点（
_start），恶意二进制可能借此执行任意代码 - 输出只反映当前环境（
/etc/ld.so.cache、默认路径）下“能被找到”的库，不等于 ELF 文件声明的全部依赖 - 它忽略
DT_NEEDED中被DT_RUNPATH或LD_LIBRARY_PATH掩盖但依然存在的条目 - 对无执行权限的
.so文件常报错，需手动加+x才能跑，这本身就不合理
真正读取 ELF 声明的全部依赖：readelf -d | grep NEEDED
这是最直接、安全、可复现的方式，只解析文件结构，不加载、不执行：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
readelf -d /path/to/binary | grep NEEDED输出形如：0x0000000000000001 (NEEDED) Shared library: [libm.so.6] - 结果不含路径，只列出 ELF 的
.dynamic段中硬编码的DT_NEEDED条目，即编译时声明的全部直接依赖 - 对任何合法 ELF（无论可执行、共享库、有无权限）都有效
- 不受
LD_LIBRARY_PATH、ld.so.cache或系统架构影响
objdump -p 也能看 NEEDED，但输出更简略
objdump -p /path/to/binary | grep NEEDED 效果接近 readelf，但：
- 输出只有
NEEDED libz.so.1这类纯文本，不带地址和括号格式 - 在某些旧版 binutils 中可能漏掉部分条目（尤其含版本符号的）
- 不显示
DT_RUNPATH或DT_RPATH，无法辅助判断搜索顺序 - 若你已装
binutils但没装elfutils，它是可用的 fallback
别忘了先确认文件确实是动态链接的 ELF
很多问题其实卡在这一步：
- 用
file /path/to/binary看输出是否含dynamically linked；若写statically linked或not an ELF file，ldd和readelf都无意义 - 若输出是
ELF 64-bit LSB pie executable，仍属动态链接，readelf -d有效 - 若
readelf -d报错Not an ELF file，说明文件不是 ELF 格式（比如是脚本、fat binary、或损坏文件）
真正关键的不是“哪个命令能跑出来”，而是你到底想问什么：是查“编译时声明了哪些依赖”，还是“此刻环境下能加载哪些”。前者必须用 readelf -d，后者才轮得到 ldd ——但后者的结果随时会变，且带风险。
