-l选项指定编译时库搜索路径，但仅影响链接阶段；运行时报“library not found”因动态链接器未获路径，需配合ld_library_path、/etc/ld.so.conf.d/或-wl,-rpath解决。
-L 选项指定库路径，但顺序和链接时机很关键
直接用 -L 指定目录是标准做法，但很多人编译通过却运行时报 error while loading shared libraries，问题不在编译阶段，而在运行时动态链接器找不到库。编译时 -L 只影响链接器搜索路径，不改变可执行文件的运行时行为。
-
-L/path/to/lib必须放在对应-lxxx之前，否则链接器会忽略它 - 多个库目录用多个
-L，例如：gcc main.o -L./lib -L/usr/local/mylib -lfoo -lbar -
-L不会递归搜索子目录，-L./lib不会自动包含./lib/arch64/ - 路径支持相对路径（如
-L../libs）和绝对路径（如-L/usr/local/openssl/lib），但避免用波浪号~，shell 展开不可靠
运行时报 “library not found” 怎么办
编译成功不代表能运行。Linux 下动态库路径在生成可执行文件时未固化，运行时依赖 LD_LIBRARY_PATH 或系统缓存。常见现象是：./a.out: error while loading shared libraries: libxxx.so: cannot open shared object file: No such file or directory。
- 临时解决：运行前设环境变量
LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH ./a.out - 永久解决（推荐）：把库路径写入
/etc/ld.so.conf.d/myapp.conf，再运行sudo ldconfig - 更稳妥的方式：编译时加
-Wl,-rpath,'$ORIGIN/../lib'，让可执行文件自带运行时搜索路径（注意单引号防止 shell 提前展开） - 验证是否生效：用
readelf -d a.out | grep RPATH或objdump -x a.out | grep RPATH
静态库和动态库对 -L 的处理差异
-L 对两者都起作用，但链接行为不同：静态库（.a）只要求存在且符号满足；动态库（.so）还需确保运行时能定位到同名文件。容易混淆的是，gcc 默认优先链接动态库，即使同目录下既有 libfoo.a 又有 libfoo.so。
- 强制链接静态库：加
-static-libgcc或对特定库用-l:libfoo.a（注意冒号和完整文件名） - 查看实际链接了哪个库：加
-v参数，观察链接器输出中attempting shared library或attempting static library行 - 若库名不标准（比如叫
mylib_v2.so），不能用-lmylib_v2，得用-L. -l:mylib_v2.so或直接传路径./mylib_v2.so
Makefile 里怎么写多个 -L
在 Makefile 中，-L 要放进链接命令的参数里，通常归入 LDFLAGS，而不是 CFLAGS。错放会导致编译阶段报错（头文件无关）或静默失效。
- 正确写法：
LDFLAGS = -L./lib -L/usr/local/ssl/lib -Wl,-rpath,'$ORIGIN/lib' - 不要写成：
CFLAGS += -L./lib—— 这会被传给预处理器，毫无作用 - 如果使用 pkg-config，它自动拼出
-L和-l，直接用$(shell pkg-config --libs openssl)更可靠 - 路径含空格？别这么干。GCC 对含空格的
-L路径支持脆弱，宁可软链到无空格路径
-rpath 和 ldconfig 的配合 —— 它决定了程序打包后能不能扔到另一台机器上直接跑。
