20、库依赖与搜索路径：-L与-l选项，LD_LIBRARY_PATH，rpath与runpath
说实话，库依赖这个问题，我当年刚入行时没少吃苦头。记得有一次，一个同事编译好的程序，拷到我机器上就是跑不起来，报什么“cannot open shared object file”。折腾了半天，才发现是库路径的问题。从那以后，我就把链接器那套搜索规则摸了个透。
今天咱们就来聊聊，编译器到底怎么找到它需要的库文件。说白了，就是两个核心问题：链接时怎么找，运行时怎么找。
20.1 静态库与动态库：先搞清楚对象
在讲搜索路径之前，得先分清楚两种库。我见过不少新手把这两者搞混，结果编译出来一堆奇怪的问题。
| 类型 | 后缀 | 链接时机 | 特点 |
|---|---|---|---|
| 静态库 | .a (Linux) / .lib (Windows) | 编译时 | 代码直接嵌入可执行文件，体积大，不依赖外部 |
| 动态库 | .so (Linux) / .dll (Windows) | 运行时 | 代码独立存在，体积小，可共享，但依赖环境 |
我个人习惯，能用动态库就用动态库。为什么呢？你想想看，如果每个程序都把libc.a嵌进去，那磁盘空间得多浪费。而且动态库更新了，程序不用重新编译就能享受新特性——当然，前提是接口没变。
20.2 链接时搜索路径：-L与-l
编译的时候，编译器怎么知道上哪儿找库？这就得靠 -L 和 -l 这两个选项了。
-l：指定库名
-l 后面跟的是库的“逻辑名”。比如 -lm 表示链接数学库，编译器会自动补全成 libm.so 或 libm.a。嗯，这里要注意，-l 后面不要加 lib 前缀，也不要加后缀名。
gcc main.o -o app -lm # 链接 libm.so 或 libm.a
gcc main.o -o app -lpthread # 链接 libpthread.so
-L：指定搜索目录
如果库不在系统默认路径（比如 /usr/lib、/usr/local/lib），你就得用 -L 告诉编译器去哪儿找。
gcc main.o -o app -L./mylibs -lfoo
这条命令的意思是：去 ./mylibs 目录下找 libfoo.so 或 libfoo.a。
-L 放在 -l 前面。虽然顺序不是强制的，但这样读起来更顺——先告诉编译器去哪儿找，再告诉它找什么。
20.3 运行时搜索路径：LD_LIBRARY_PATH
编译通过了，程序也生成了。但一运行，又报错。为什么？因为动态库是在运行时才加载的。系统得知道上哪儿去找 .so 文件。
这时候 LD_LIBRARY_PATH 就派上用场了。它是一个环境变量，告诉动态链接器（ld.so）去哪些目录搜索库。
export LD_LIBRARY_PATH=/home/user/mylibs:$LD_LIBRARY_PATH
./app
LD_LIBRARY_PATH 设成了全局变量，结果导致系统命令都用了错误的库版本，整个服务器差点崩了。所以，千万别在生产环境全局设置 LD_LIBRARY_PATH。只在测试或临时调试时用。
20.4 硬编码搜索路径：rpath与runpath
LD_LIBRARY_PATH 虽然方便，但不够“硬”。你想想看，如果程序发布给用户，用户还得自己设环境变量，多麻烦。更好的办法是把搜索路径直接编译进可执行文件里。
这就是 rpath 和 runpath 的由来。
rpath：编译时指定
用 -Wl,-rpath, 选项，可以把路径硬编码到 ELF 文件里。
gcc main.o -o app -L./mylibs -lfoo -Wl,-rpath,/home/user/mylibs
这样，程序运行时就会先去 /home/user/mylibs 找库，找不到再去系统默认路径。
rpath vs runpath：谁优先级高？
这两个东西很像，但有一个关键区别：搜索顺序。
| 属性 | 搜索顺序 | 特点 |
|---|---|---|
| rpath | rpath → 系统默认路径 | LD_LIBRARY_PATH 被忽略 |
| runpath | LD_LIBRARY_PATH → runpath → 系统默认路径 | 允许环境变量覆盖 |
我个人更推荐用 runpath。为什么呢？因为它给了你灵活性。如果用户想临时换一个库版本，设个 LD_LIBRARY_PATH 就行。而 rpath 太“霸道”了，直接忽略环境变量，调试起来很麻烦。
设置 runpath 的方法：
gcc main.o -o app -L./mylibs -lfoo -Wl,-rpath,/home/user/mylibs -Wl,--enable-new-dtags
--enable-new-dtags 这个选项就是告诉链接器：用 runpath 代替 rpath。
20.5 搜索顺序全景图
说了这么多，咱们来画个图，把整个搜索流程理清楚。
这张图把整个流程串起来了。你想想看，从编译到运行，库的搜索其实是一套层层递进的规则。搞懂了它，以后遇到“找不到库”的问题，心里就有底了。
20.6 实战建议
说了这么多理论，来点实际的。我总结了几条经验，希望能帮你少走弯路。
- 开发阶段： 用
LD_LIBRARY_PATH临时指定库路径，方便调试。 - 发布阶段： 用
-Wl,-rpath,配合--enable-new-dtags设置 runpath，把路径硬编码进程序。 - 检查工具： 用
ldd命令查看程序依赖了哪些动态库，以及它们从哪里加载。
ldd app
# 输出示例：
# linux-vdso.so.1 (0x00007ffe3b7f0000)
# libfoo.so => /home/user/mylibs/libfoo.so (0x00007f8a1c400000)
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8a1c000000)
-L 和 -l，运行时靠 LD_LIBRARY_PATH 或 rpath/runpath。记住，runpath 比 rpath 更灵活，是我个人推荐的做法。
好了，关于库依赖和搜索路径，今天就聊到这儿。下次遇到“找不到库”的问题，别慌，按这个思路排查，准能搞定。