ldconfig -p 查看动态链接器缓存中的共享库，反映系统“认得”的库而非实时磁盘扫描；需确保路径写入 /etc/ld.so.conf.d/ 并执行 sudo ldconfig 刷新。
ldconfig -p 列出系统已知的所有 .so 库路径
系统启动时会扫描 /etc/ld.so.conf 及其包含的配置文件（比如 /etc/ld.so.conf.d/*.conf），把所有指定目录记进缓存，ldconfig -p 就是查这个缓存——不是实时遍历磁盘，所以快、准、反映的是当前链接器“认得”的库。
常见错误：运行了 sudo ldconfig 但 ldconfig -p | grep xxx 还找不到，大概率是刚加的路径没写进 /etc/ld.so.conf 或对应 .conf 文件里，或者忘了 sudo 权限导致配置没生效。
- 确认路径已写入：
cat /etc/ld.so.conf.d/mylib.conf（内容应为一行绝对路径，如/opt/myapp/lib） - 刷新缓存必须用
sudo ldconfig，普通用户执行无效果 -
ldconfig -p输出中每行末尾的(libc6,x86-64)表示 ABI 兼容性，32 位程序看不到标x86-64的库
find /usr -name "libxxx.so*" 适合临时定位未知位置的库文件
当 ldconfig -p 找不到，但你知道库名（比如 libssl.so），又不确定它被装在哪，就得直接扫磁盘。别一上来就 find / -name ...，权限拒绝多、速度慢、结果杂；优先限定在常规安装区。
典型场景：自己编译安装了某个库，没走系统包管理，也没配 ld.so.conf，运行程序时报 error while loading shared libraries: libxxx.so: cannot open shared object file。
- 常用范围：
find /usr /opt /usr/local -name "libz.so*"（注意通配符*匹配版本号，如libz.so.1.2.11） - 加
2>/dev/null屏蔽权限错误：find /usr -name "libcurl.so*" 2>/dev/null - 如果只想要最新版软链（如
libcurl.so→libcurl.so.4.7.0），加-type l：find /usr -type l -name "libcurl.so"
LD_LIBRARY_PATH 环境变量是运行时临时覆盖库搜索路径的快捷方式
它不改系统配置，只对当前 shell 及其子进程生效，适合调试、CI 测试或临时跑一个依赖非标准路径库的程序。但它不解决根本问题，且容易掩盖路径配置错误。
容易踩的坑：设了 LD_LIBRARY_PATH 后程序能跑，就以为“搞定了”，结果换终端、换用户、做成 systemd 服务就失效——因为环境变量没继承。
- 临时生效：
LD_LIBRARY_PATH="/opt/mylib:$LD_LIBRARY_PATH" ./myapp - 不要 export 全局（尤其不要写进
~/.bashrc），否则可能干扰其他程序加载同名库 - 使用前先
echo $LD_LIBRARY_PATH确认值正确，空值或拼错路径不会报错，只会静默跳过 - 和
ldd ./myapp结合看：输出里某行显示not found，说明该库不在当前LD_LIBRARY_PATH或系统缓存路径里
ldd 命令显示可执行文件实际依赖的 so 文件及其解析状态
ldd 不是列出“所有可能用到的库”，而是模拟动态链接器行为，告诉你当前环境下每个依赖是否能找到、具体加载自哪个路径。它是验证配置是否生效的最终裁判。
关键点：它只报告运行时链接阶段的结果，不关心头文件、静态库或编译期设置。
- 正常输出示例：
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f...) - 出现
not found：说明该库名在LD_LIBRARY_PATH和ldconfig缓存路径中都未命中 - 出现
undefined symbol类错误？那不是路径问题，是库版本不匹配或 ABI 不兼容，ldd不管这个 - 对已 strip 的二进制或 setuid 程序，
ldd可能拒绝执行，改用readelf -d ./binary | grep NEEDED看依赖名，再手动查
ldconfig 缓存；或者你改了配置，却忘了 sudo ldconfig 刷新——这两步缺一不可。 
