最可靠方法是直接查看 /proc/[PID]/maps，它真实反映运行中进程内存映射的 .so 文件，包括 dlopen 动态加载的库；常用命令为 sudo cat /proc/1234/maps | grep '\.so' | awk '{print $6}' | sort -u，或使用 pldd 1234（需 procps-ng）；lsof -p 1234 | awk '$4 ~ /\.so$/ {print $9}' | sort -u 也可用但受限于权限；ldd 对运行中进程无效，仅静态分析。
怎么查运行中进程实际加载了哪些 .so 文件
直接看 /proc/[PID]/maps 最可靠，它反映进程当前内存里真实映射的 SO 库，包括 dlopen 动态加载的库，不会漏。
常用命令组合：
-
sudo cat /proc/1234/maps | grep '\.so' | awk '{print $6}' | sort -u—— 只取路径列，去重 -
pldd 1234—— 更简洁，但要求系统装了procps-ng（多数发行版默认有） -
lsof -p 1234 | awk '$4 ~ /\.so$/ {print $9}' | sort -u—— 依赖文件描述符，部分容器或特权受限环境可能权限不足
注意：ldd 对运行中进程无效，它只分析可执行文件静态依赖，且不体现运行时 LD_LIBRARY_PATH 或 RUNPATH 的实际效果。
为什么 ldd 显示 not found 却能跑起来
因为 ldd 模拟的是“当前 shell 环境下”的链接行为，而进程可能通过以下方式绕过它：
- 二进制里硬编码了
RUNPATH（用readelf -d ./prog | grep RUNPATH查） - 启动时设置了
LD_LIBRARY_PATH，但你运行ldd的 shell 没设 - 用了
patchelf --set-rpath修改过运行时路径
验证方法：在同个环境里跑 LD_DEBUG=libs ./prog 2>&1 | head -20，能看到真实搜索路径和匹配过程。
LD_LIBRARY_PATH 怎么设才不踩坑
临时设置没问题，但永久写进 ~/.bashrc 是高危操作——它会让所有子进程继承，容易导致不同程序加载错版本的同名 .so。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
更稳妥的做法：
- 调试时只在命令前加：
LD_LIBRARY_PATH=/opt/mylib ./myapp - 服务部署用 systemd：在
[Service]段写Environment=LD_LIBRARY_PATH=/opt/mylib - 真正要系统级生效，走
/etc/ld.so.conf.d/myapp.conf+sudo ldconfig，这样路径进缓存，不污染环境变量
检查是否生效：echo $LD_LIBRARY_PATH 看值，再用 ldd ./myapp | grep '=>' 确认目标库是否指向预期路径。
ldconfig -p 找不到库？先确认它是不是真被系统“认得”
ldconfig -p 查的是 /etc/ld.so.cache，不是磁盘实时扫描。如果刚把 .so 放进 /usr/local/lib 却查不到，大概率是没刷新缓存或路径没注册。
排查步骤：
- 确认路径已写入：
cat /etc/ld.so.conf.d/*.conf | grep -F '/usr/local/lib' - 手动刷新：
sudo ldconfig（必须用sudo） - 验证缓存内容：
sudo ldconfig -v 2>/dev/null | grep '/usr/local/lib'
如果库在非标准路径（比如 /opt/app/lib），别用 find 盲扫，优先走 ld.so.conf.d 配置 + ldconfig，否则每次重启都要重配。
