ldd仅显示“缺什么”，不揭示原因或解决方案；需重点关注not found（库缺失）、空路径地址（版本/架构不匹配）、非常规路径（易冲突）三类输出，排查须结合file、readelf、dpkg/rpm及ldconfig，禁用手动复制.so。
Linux 中排查软件包依赖缺失，核心是分清“缺什么”和“为什么找不到”，不能只盯着报错就盲目装包。关键在用对命令、看懂输出、走对路径。
先用 ldd 定位真正缺失的库
运行 ldd ./程序名，重点盯三类行：
-
“not found”：如
libssl.so.1.1 => not found，说明系统没这个文件，得查哪个包提供它 -
空括号：如
libz.so.1 => (0x00007f...)，括号里没路径，通常是版本不匹配或LD_LIBRARY_PATH没生效 -
指向非标准路径：比如指向
/opt/xxx/lib/或/usr/local/lib/，大概率是第三方私有库，容易和系统库冲突
查清楚谁提供了这个 .so 文件
光知道名字不够，得确认系统里有没有对应包：
- Debian/Ubuntu 系：dpkg -S libssl.so.1.1（查已安装包）或 apt search libssl（查可用包）
- RHEL/CentOS/Fedora 系：rpm -qf /usr/lib64/libssl.so.1.1（查已安装）或 dnf provides "*/libssl.so.1.1"（查源中包）
- 如果库根本不在标准路径，先用 find /usr -name "libssl.so.*" 2>/dev/null 找找它在哪
别跳过架构和 glibc 兼容性检查
明明装了却 still not found？很可能是底层不匹配：
- 用 file ./程序名 和 file /path/to/libxxx.so 对比，确保都是
ELF 64-bit或都为32-bit - 运行 ldd ./程序名 时若提示
version GLIBC_2.34 not found，说明程序编译用的 glibc 比当前系统新，需升级系统或换兼容版本程序 - 检查动态链接器是否支持该 ABI：getconf GNU_LIBC_VERSION 查当前 glibc 版本
修复后必须刷新缓存或验证路径
装完库不等于系统立刻认得，这几步漏一不可：
- 如果把库放到了
/usr/local/lib/或自定义目录，要写进/etc/ld.so.conf.d/my.conf，再执行 sudo ldconfig - 临时测试可加环境变量：LD_LIBRARY_PATH="/path/to/lib:$LD_LIBRARY_PATH" ./程序名，但别长期依赖它
- 确认是否生效：ldd ./程序名 再看一遍，同时用 readelf -d ./程序名 | grep RUNPATH 查程序是否硬编码了搜索路径
