根本原因是编译时-L仅影响链接阶段的库查找，不写入可执行文件；-Wl,-rpath才将运行时库路径写入ELF的DT_RPATH段供动态链接器启动时使用，正确写法需用逗号分隔、指定绝对路径，并可通过readelf -d确认写入成功。
编译时硬编码运行时库路径用 -Wl,-rpath
程序跑起来找不到 .so，根本原因是：编译时用 -L 告诉了 gcc 上哪找库，但生成的可执行文件本身并不“记得”这个路径。-Wl,-rpath 就是把路径直接写进 ELF 文件的 DT_RPATH 段，让动态链接器一启动就去那里找。
正确写法是：
gcc -I/home/user/include -L/home/user/lib -lmylib -Wl,-rpath,/home/user/lib -o app app.c
注意几点：
-
-Wl,是 GCC 向链接器ld传参的开关，逗号不能少，-rpath后面不加空格，直接跟路径 - 路径必须是运行时真实存在的绝对路径；相对路径（如
-Wl,-rpath,./lib）在大多数系统上会被忽略 - 可指定多个路径，用冒号分隔：
-Wl,-rpath,/path1:/path2 - 用
readelf -d app | grep PATH或objdump -p app | grep RPATH能确认是否写入成功
LD_LIBRARY_PATH 临时生效但不可靠
这是最常被滥用的方式：通过环境变量告诉动态链接器额外搜索路径。它确实能快速验证问题，但不适合部署。
典型操作：
export LD_LIBRARY_PATH=/home/user/lib:$LD_LIBRARY_PATH ./app
问题在于：
- 只对当前 shell 及其子进程有效，重启终端或换用户就失效
- 如果程序被
sudo、systemd、crontab 或其他守护进程拉起，该变量通常不继承 - 多个程序共用同一变量时容易冲突，比如 A 程序依赖 libA.so，B 程序依赖同名但不同版本的 libA.so
- 某些安全策略（如
secure_getenv）会在 setuid 程序中自动清空LD_LIBRARY_PATH
永久生效选 /etc/ld.so.conf.d/ 而非改 /etc/ld.so.conf
想让所有用户、所有程序都识别你的库路径，且不依赖环境变量，就走系统级缓存机制。核心是两步：写配置 + 刷新缓存。
推荐做法：
echo "/home/user/lib" | sudo tee /etc/ld.so.conf.d/mylib.conf sudo ldconfig
为什么不用直接改 /etc/ld.so.conf？
- 该文件可能被包管理器覆盖（如 apt/yum 升级时）
-
/etc/ld.so.conf.d/下的.conf文件支持按模块管理，更清晰、易维护 -
ldconfig默认会扫描整个d/目录，无需手动维护主文件 - 确认是否生效：运行
ldconfig -p | grep mylib，能看到你的库才说明成功
ldd 报 not found 时先看它到底在查哪些路径
ldd ./app 输出里出现 libxxx.so => not found 不代表路径一定错，而是说明当前搜索顺序下没匹配到。要定位真正瓶颈，得知道它查了哪些地方。
运行这行命令看完整搜索链：
LD_DEBUG=libs ./app 2>&1 | grep "search path"
你会看到类似这样的输出：
search path=/home/user/lib (RPATH from file ./app) search path=/usr/local/lib (LD_LIBRARY_PATH) search path=/etc/ld.so.cache search path=/lib:/usr/lib (default)
关键点：
- RPATH 的优先级最高，但只在你用了
-Wl,-rpath时才存在 -
LD_LIBRARY_PATH排第二，但它为空时不会显示这一行 - 如果你没配任何东西，就只剩系统默认路径 —— 这时候
not found就是真找不到 - 注意
ldd本身是个 shell 脚本，有时会误报；用LD_DEBUG=libs才是运行时真实行为
RPATH 和 LD_LIBRARY_PATH，又在 /etc/ld.so.conf.d/ 里加了路径，而某个库恰好在多个位置都存在不同版本 —— 此时哪个被加载，取决于顺序，而不是“谁更显眼”。 
