-L指定库搜索路径，-l指定库名；链接器按命令行顺序依次处理，-L必须置于对应-l之前，否则无效。
g++里-L和-l到底谁先找谁？
直接说结论：-L指定路径，-l指定库名，但链接器实际查找顺序不是“先-L后-l”，而是按命令行出现顺序依次扫描所有-L路径，对每个-lxxx尝试在这些路径中找libxxx.a或libxxx.so。如果-L写在-l后面，那它对前面的-l完全无效。
常见错误现象：明明写了-L/path/to/lib -lmylib却报undefined reference to 'xxx'，很可能是因为-L位置靠后，或者libmylib.so根本不在那个路径下（比如实际是libmylib.so.2但没建软链接）。
-
-L必须放在对应-l之前，多个-L按从左到右顺序搜索 -
-lmylib会依次查找libmylib.so→libmylib.a（静态优先取决于是否加-static） - 路径中不能有空格；若必须含空格，整个
-L参数要用引号包裹，如-L"/path/with space"
为什么加了-L还是找不到动态库运行时？
-L只影响编译链接阶段，不影响程序运行时的库加载。运行时报error while loading shared libraries: libxxx.so: cannot open shared object file，说明系统不知道去哪找这个so文件。
解决方法不是改-L，而是告诉动态链接器：
立即学习“C++免费学习笔记（深入）”；
- 临时生效：运行前设
LD_LIBRARY_PATH="/path/to/lib:$LD_LIBRARY_PATH"（注意：仅限开发调试，不推荐部署） - 永久生效（需root）：把路径写入
/etc/ld.so.conf.d/mylib.conf，再运行sudo ldconfig - 编译时硬编码路径：用
-Wl,-rpath,/path/to/lib（-Wl,表示把后面内容传给链接器），这样生成的可执行文件自带运行时搜索路径
libxxx.so和libxxx.so.1.2.3，-l应该写哪个？
-lxxx永远只写基础名（去掉lib前缀和版本后缀），链接器自己负责匹配。关键在于目标目录下是否存在符合规范的符号链接。
例如，你有libcurl.so.4.7.0，但没有libcurl.so，那么-lcurl就会失败——链接器只认libcurl.so这个“soname入口”。实际项目中，安装库时通常会自动创建libcurl.so → libcurl.so.4.7.0这样的软链接。
- 检查软链接是否存在：
ls -l /path/to/lib/libxxx.so* - 手动补软链接（开发机临时用）：
ln -sf libxxx.so.1.2.3 /path/to/lib/libxxx.so - 用
readelf -d your_executable | grep RPATH确认运行时路径是否生效
静态库（.a）和动态库（.so）混用时要注意什么？
默认情况下，链接器优先选.so。如果你明确要静态链接某个库（比如避免部署时缺so），得用-Wl,-Bstatic -lxxx -Wl,-Bdynamic包住它，否则-static会全局强制静态，可能连libc都静态进去，导致不可移植。
- 只对特定库静态：
g++ main.cpp -Wl,-Bstatic -lmylib -Wl,-Bdynamic -lpthread -o app - 验证是否真静态进了：
nm app | grep "U mylib_function"—— 如果还有U（undefined），说明没链上 - 静态库路径必须用
-L且.a文件存在；动态库即使指定了-L，只要同名.so存在，就不会退回去用.a
最常被忽略的是-rpath和软链接这两步——编译通过不代表运行能跑，尤其跨机器部署时，ldd ./app一看依赖就全明白了。
