必须运行 sudo ldconfig 才能使 /etc/ld.so.conf 修改生效，否则系统仍用旧缓存；路径需写入 /etc/ld.so.conf.d/ 下的 .conf 文件，库须符合 libxxx.so.x 命名且含有效 soname。
为什么改了 /etc/ld.so.conf 还是找不到库？
直接改完文件不运行 sudo ldconfig，系统压根不会重新加载配置。这是最常被忽略的一步——ld.so.conf 只是静态配置，ldconfig 才是真正生成缓存 /etc/ld.so.cache 的命令。没执行它，所有修改都无效。
常见错误现象：./a.out: error while loading shared libraries: libxxx.so: cannot open shared object file，但你确认库文件明明在刚加的路径里。
- 必须用
sudo ldconfig（普通用户权限不够） - 建议加
-v参数观察是否真扫描到了你的路径：sudo ldconfig -v 2>&1 | grep your_path - 如果路径下有库但没被识别，检查库文件权限（至少需
rx）、是否为 ELF 格式（file libxxx.so）、架构是否匹配（如 x86_64 库不能用在 arm64 上）
该往 /etc/ld.so.conf 里写什么路径？
只写目录路径，一行一个，不能带通配符、不能写具体库名、不能加空格或注释符号（# 在这里不是注释，会被当路径一部分）。例如：
/usr/local/lib64 /opt/myapp/lib
更推荐的做法是：不要直接编辑 /etc/ld.so.conf，而是新建 /etc/ld.so.conf.d/myapp.conf（文件名任意，但必须以 .conf 结尾），然后写入路径。这样便于管理、卸载时可一键删除，也避免误改主配置。
-
/etc/ld.so.conf.d/下所有.conf文件都会被自动读取 - 路径中不要包含
$LD_LIBRARY_PATH这类变量，它在这里不展开 - 避免写
/home/user/lib这类用户目录——系统级动态链接器默认不信任非标准位置，且多用户环境下不可靠
LD_LIBRARY_PATH 和 ld.so.conf 到底谁优先？
LD_LIBRARY_PATH 环境变量优先级高于 ld.so.conf，但它只影响当前 shell 及其子进程，且对 setuid 程序完全无效（出于安全限制）。而 ld.so.conf 是系统级配置，生效范围广，但需要 ldconfig 刷新。
使用场景要分清：
- 临时调试：用
LD_LIBRARY_PATH=/path/to/lib ./myapp - 部署服务：必须走
/etc/ld.so.conf.d/+ldconfig，否则 systemd 服务或 crond 任务根本看不到你的路径 - 混合使用时注意冲突：比如
LD_LIBRARY_PATH里有同名库，会覆盖ld.so.conf中的版本，可能引发 ABI 不兼容
为什么 ldconfig -p | grep xxx 查不到刚加的库？
ldconfig -p 显示的是当前 /etc/ld.so.cache 缓存里的库列表，不是实时扫描磁盘。所以即使路径已写入配置、也执行过 ldconfig，仍可能查不到——常见原因有三个：
- 库文件名不符合命名规范：动态库必须是
libxxx.so.x格式（如libz.so.1），不能是libxxx.so软链接本身（ldconfig只索引带 soname 的文件） - 缺少 soname：用
readelf -d /path/to/libxxx.so | grep SONAME检查，若为空，需重建库或用patchelf --set-soname libxxx.so.1 libxxx.so - 路径权限问题：
ldconfig默认跳过 world-writable 目录（如/tmp），也会跳过没有执行权限的目录
真正可靠的方式是先确认 ldconfig -v 输出里有没有扫到你的目录，再看该目录下是否列出了目标库——别只信 -p。
