ldd显示“not found”但程序仍可运行，因其仅模拟静态链接器行为，不读/etc/ld.so.conf.d/、不加载ld_preload、也不走二进制硬编码的runpath；真实运行由ld-linux.so按完整规则查找。
ldd 是最直接的起点，但它经常报“not found”却程序照常运行，或者对某些二进制完全失效——这不是你操作错了，是它本身机制有盲区。
为什么 ldd 会显示 not found 却能正常运行
因为 ldd 模拟的是静态链接器行为，不读 /etc/ld.so.conf.d/、不加载 LD_PRELOAD、也不走二进制里硬编码的 RUNPATH。真实运行时，ld-linux.so 会按完整规则查找库。
- 先检查是否设置了
LD_LIBRARY_PATH：echo $LD_LIBRARY_PATH - 看二进制自己带的搜索路径：
readelf -d /path/to/binary | grep RUNPATH - 确认系统缓存已更新：
sudo ldconfig -v | grep yourlib（比如刚装了新库但没刷缓存，ldd就看不见） - 容器或 chroot 环境下，
ldd更容易误判——它看不到你手动 setenv 的LD_LIBRARY_PATH后再 exec 的上下文
readelf -d 和 objdump -p 都只输出 NEEDED，怎么知道实际路径
readelf -d binary | grep NEEDED 和 objdump -p binary | grep NEEDED 只列出库名（如 libc.so.6），不给路径。它们安全、不执行程序，但需要你手动补全查找逻辑。
- 用
ldconfig -p | grep libc.so.6查系统级缓存中已注册的路径 - 若没结果，去常见路径手工找：
/lib64/、/usr/lib64/、/usr/lib/x86_64-linux-gnu/ - 注意：有些二进制把
RPATH或RUNPATH打包进去了，得用readelf -d binary | grep -E "(RPATH|RUNPATH)"提取后，再进那些目录里ls *.so* - 静态链接、PIE 或 musl 编译的程序，这两条命令会完全不输出
NEEDED条目——不是漏了，是根本没动态依赖
strace 能看到真实加载行为，但别滥用
当 ldd 和 readelf 都无法还原现场时，strace -e trace=openat,openat64 /path/to/binary true 2>&1 | grep '\.so' 是终极手段：它捕获程序启动时真实 openat() 的 so 文件路径。
- 必须加
true（或任意轻量命令）作为参数，否则部分程序会拒绝初始化 - 输出里出现
openat(AT_FDCWD, "/opt/myapp/lib/libfoo.so.1", ...)这种路径，就是它真正在用的库 - 性能开销大，不能用于生产环境长期监听；且对 setuid 程序可能被内核拦截
- 如果看到大量
openat(..., "libxxx.so.2") = -1 ENOENT，说明程序在 fallback 查找，最终靠RUNPATH或ldconfig缓存才成功
ldd 不校验符号版本，readelf 不反映运行时环境，strace 又太重——查依赖这事，从来不是单个命令能闭环的。
