ldd显示“not a dynamic executable”说明目标文件非动态链接，常见于静态编译、跨架构二进制、内核模块或ELF重定位文件；应先用file命令确认类型，再视情况使用readelf -d分析动态节。
直接用 ldd 查看可执行文件或共享库的动态依赖，但必须注意它不适用于静态链接、交叉编译目标或 stripped 后丢失符号的二进制文件。
为什么 ldd 有时显示 “not a dynamic executable”？
这通常意味着目标文件根本没使用动态链接——比如是静态编译的（gcc -static），或是裸 ELF 可重定位文件（.o）、内核模块（.ko）等。此时 ldd 完全无能为力。
- 先用
file命令确认类型：file /path/to/binary—— 输出含 “dynamically linked” 才能用ldd - 若输出是 “statically linked”，得换思路：用
readelf -d binary | grep NEEDED看是否真有动态节；没有就说明确实无运行时依赖 -
ldd本身是 shell 脚本，会尝试用 loader 加载目标来推导依赖，所以对非本地 ABI 架构（如 ARM 二进制在 x86 上）也会失败
如何安全地用 ldd 避免执行恶意代码？
ldd 在某些旧版本（glibc LD_TRACE_LOADED_OBJECTS=1 并真正执行目标来获取依赖，这意味着如果二进制被篡改过，ldd 可能触发 payload。
- 优先用
objdump -p binary | grep NEEDED或readelf -d binary | grep NEEDED—— 这两个命令只读取 ELF 结构，不执行任何代码 - 现代 glibc（≥2.34）已默认让
ldd使用LD_DEBUG=files模式，更安全，但仍建议对不可信二进制保持警惕 - 绝对不要对来源不明的二进制跑
ldd，尤其当它可能有 setuid 权限时
ldd 输出里出现 “not found” 怎么办？
这表示系统找不到某个 NEEDED 条目声明的共享库，常见于自定义安装路径或缺失兼容包。
- 检查库名是否完整：比如显示
libfoo.so.1 => not found，实际文件可能是libfoo.so.1.2.3，需确保软链接存在或ldconfig缓存已更新 - 确认
LD_LIBRARY_PATH是否漏设，或/etc/ld.so.conf.d/下没加对应路径后忘记运行sudo ldconfig - 用
find /usr -name 'libfoo*' 2>/dev/null或locate libfoo.so找文件位置，再手动验证是否在 loader 搜索路径中（cat /etc/ld.so.cache | strings | grep foo）
真正麻烦的是那些隐式依赖：比如某 so 文件内部又 dlopen("libbar.so")，这种不会出现在 ldd 输出里，得靠 strace -e trace=openat,openat64 ./binary 2>&1 | grep bar 抓运行时加载行为。
