ldd仅显示“缺什么”，不揭示原因或解决方案；需重点关注三类输出：not found（库缺失）、空路径地址（版本/架构不匹配）、非常规路径（易冲突）；排查须结合file、readelf、dpkg/rpm及ldconfig，禁用手动复制.so。
直接运行 ldd 只能告诉你“缺什么”，不能告诉你“为什么缺”或“怎么补”——它不检查环境变量，也不验证库文件权限或架构兼容性。
怎么看 ldd 输出里真正要命的那几行
别被满屏路径带偏，只盯三类关键信息：
-
libssl.so.1.1 => not found：库名明确，但系统在/etc/ld.so.cache、LD_LIBRARY_PATH和默认路径（如/lib、/usr/lib）里都找不到对应文件 -
libz.so.1 => (0x00007f...)：右边没路径、只有地址，说明动态链接器找到了库，但加载失败——常见于版本不匹配、ABI 不兼容或 32/64 位混用 -
libcustom.so => /opt/app/lib/libcustom.so：路径非常规，容易和系统库冲突，尤其当多个程序各自带私有.so时，LD_LIBRARY_PATH一乱就崩
为什么明明有 .so 文件，ldd 还报 not found
这不是 ldd 的错，是动态链接器实际行为和你预期不一致。常见真实原因：
-
LD_LIBRARY_PATH没生效：运行echo $LD_LIBRARY_PATH确认拼写、冒号分隔、路径存在；注意ldd默认会清空该变量，要用env LD_LIBRARY_PATH=... ldd ./binary才能模拟真实环境 - 二进制自带
RUNPATH或RPATH：执行readelf -d ./binary | grep -E "(RUNPATH|RPATH)"，如果输出非空，说明它硬编码了搜索路径，LD_LIBRARY_PATH会被忽略 - 刚装完库就跑
ldd：系统缓存没更新，必须执行sudo ldconfig刷新/etc/ld.so.cache - 架构不匹配：用
file ./binary和file /path/to/libxxx.so对比，确保都是ELF 64-bit LSB pie executable或同为 32-bit
查到 not found 后，别急着复制 .so 到 /usr/lib
手动扔文件是运维事故高发动作，后果包括：apt upgrade 覆盖、符号冲突、无法被包管理器追踪。正确路径是：
- 先查哪个包提供它：
dpkg -S libssl.so.1.1（Debian/Ubuntu），或rpm -qf /usr/lib64/libssl.so.1.1（RHEL/Fedora） - 若查不到，再确认库名是否准确——
libssl.so.1.1可能实际叫libssl.so.3，用find /usr -name "libssl*.so*" 2>/dev/null扫一遍 - 优先安装官方源包：
sudo apt install libssl1.1或sudo dnf install openssl-libs - 实在要走自定义路径，加进
/etc/ld.so.conf.d/myapp.conf再sudo ldconfig，别依赖环境变量
对不可信二进制，绝对别用 ldd
ldd 底层会调用目标程序自身（通过 LD_TRACE_LOADED_OBJECTS=1），恶意构造的 ELF 可借此执行任意代码。安全替代方案只有两个：
-
readelf -d ./malicious.bin | grep NEEDED：直接读 ELF 的.dynamic段，零风险 -
objdump -p ./malicious.bin | grep NEEDED：效果类似，输出更紧凑
这两条命令不加载、不执行、不依赖 libc 兼容性，是分析未知二进制依赖的唯一直接手段。
