-L参数必须放在-l之前，否则不生效；它仅影响后续的-l选项，指定链接时库文件搜索路径，但对运行时无效。
-L参数必须放在-l之前，否则链接会失败
gcc在解析命令行时是顺序扫描的，-L只影响它**之后**出现的-l参数。如果把-lm -L/usr/local/lib写成这样，-L根本不会作用于-lm，链接器仍然只在默认路径（/usr/lib等）里找libm.so。
正确顺序是：gcc main.c -L/usr/local/lib -lm -o main。多个-L可以叠加，比如-L/path/a -L/path/b，搜索顺序就是从左到右依次尝试。
- 每个
-L只对它后面第一个（或后续）的-l生效，不是全局设置 - 如果库目录路径含空格，必须用引号包裹，例如
-L"/opt/my libs" -
-L指定的是**目录路径**，不是文件路径；不能写成-L/usr/lib/libfoo.so
-L指定的路径不包含库文件时，报错信息是“cannot find -lxxx”
典型错误：/usr/bin/ld: cannot find -lfoo。这表示链接器在所有已知路径（包括-L指定的）中都没找到libfoo.so或libfoo.a。
常见原因有三个：
- 库文件名不匹配：比如你放了
libfoo.so.1.2，但没建软链接libfoo.so→ ld只认libfoo.so（动态）或libfoo.a（静态） - 权限问题：目录不可读，或
.so文件没有可读权限 - 路径写错：比如
-L/opt/foo/lib实际是/opt/foo/libs，少了一个s
验证方法：用ls -l /your/path/libxxx.so确认文件存在且可读；用readelf -d your_executable | grep NEEDED确认是否成功链接。
静态库和动态库共存时，-L + -l 默认优先链接动态库
当/mylib下同时存在libfoo.so和libfoo.a，执行gcc main.c -L/mylib -lfoo会链接.so。这不是bug，而是ld的默认行为。
要强制链接静态库，有两个办法：
- 显式写全路径：
gcc main.c /mylib/libfoo.a -o app - 加
-static开关：gcc main.c -static -L/mylib -lfoo→ 但注意这会**全局静态链接**所有库，不推荐
更稳妥的做法是用-Wl,-Bstatic局部控制：gcc main.c -L/mylib -Wl,-Bstatic -lfoo -Wl,-Bdynamic -lc，其中-lc仍走动态链接。
运行时找不到动态库，-L参数完全不起作用
-L只在**编译链接阶段**起作用，生成可执行文件后就失效了。运行时报error while loading shared libraries: libfoo.so: cannot open shared object file，说明系统运行时找不到该库。
解决运行时路径问题，不能靠-L，而要用：
-
LD_LIBRARY_PATH=/mylib ./app（临时，仅当前shell有效） - 把
/mylib写入/etc/ld.so.conf.d/foo.conf，再运行sudo ldconfig（永久生效） - 编译时加
-Wl,-rpath,/mylib：让可执行文件自带运行时库路径，最可靠
容易忽略的一点：-rpath里的路径是**运行时路径**，不是编译时路径；它会被硬编码进二进制，所以别写相对路径或开发机路径。
