Linux怎么查看进程的共享库依赖 Linux下pldd与ldd命令详解

ldd查的是可执行文件静态声明的依赖，pldd查的是进程运行时实际加载的共享库；ldd仅解析ELF的DT_NEEDED条目且不接触进程内存，无法反映dlopen、LD_PRELOAD等动态行为，而pldd通过读取/proc/PID/maps直接获取运行时真实映射，需root权限。

直接说结论： ldd 查的是「可执行文件静态声明的依赖」，pldd 查的是「进程运行时实际加载的共享库」——两者根本不是一回事，不能互相替代。

为什么 ldd 不能用来查正在运行的进程？

ldd 本质是解析 ELF 文件的 DT_NEEDED 条目，再模拟动态链接器加载行为。它根本不接触进程内存，只读磁盘上的二进制文件。

• 对已启动的进程，ldd /proc/1234/exe 看到的仍是该程序**编译时声明的依赖**，不是它此刻真正用到的库（比如 dlopen 动态加载的）
• 如果进程用了 LD_PRELOAD、自定义 rtld 或修改了 ld.so.cache，ldd 完全无法反映
• 更严重的是：ldd 在某些旧版 glibc 中会真实执行目标程序的初始化代码，对不可信二进制有安全风险

pldd 是什么，为什么必须用 root 运行？

pldd 直接读取 /proc//maps 和 /proc//mem，从中提取当前进程地址空间里所有被 mmap 的 .so 文件路径。这属于内核暴露的运行时状态。

• 必须 sudo pldd ，因为普通用户无权读取 /proc//mem
• 输出里能看到 libpython3.10.so.1.0 这类由 import 触发加载的库，ldd 永远列不出来
• 若进程已崩溃或处于 T（stopped）状态，pldd 可能失败并报 Operation not permitted

实际排查时怎么选：ldd 还是 pldd？

看你要解决的问题类型：

Docker Desktop（linux）

当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。

下载

• 程序启动就报 error while loading shared libraries: libxxx.so: cannot open shared object file → 用 ldd ./myapp | grep "not found"
• 程序能启动但运行中突然 segfault，怀疑某库版本不匹配或被覆盖 → 用 sudo pldd | grep libxxx 确认实际加载的是哪个路径
• 想验证 LD_LIBRARY_PATH 是否生效 → pldd 输出里会出现你指定路径下的库；ldd 不受运行时环境变量影响
• 检查是否真有 dlopen 行为 → pldd 会列出那些没出现在 ldd 结果里的库，比如 libcuda.so.1（CUDA 应用常见）

安全替代方案：不用 ldd 也能看静态依赖

当面对来源不明的二进制，又需要确认它声明了哪些库时，避免 ldd 的执行风险：

• readelf -d ./malware.bin | grep NEEDED —— 最轻量，只解析 ELF 动态段
• objdump -p ./malware.bin | grep NEEDED —— 输出格式稍不同，但等价
• 注意：这两个命令都**不会触发任何代码执行**，也不依赖 glibc 版本

真正容易被忽略的点是：pldd 看到的库路径可能来自 /proc//maps 的 pathname 字段，而这个字段在内核中可能为空（比如匿名 mmap 或被 unlink 的 so），此时 pldd 就显示 [anon] —— 这种情况只能结合 strace -e trace=openat,openat64 -p 追踪实际打开行为。