“cannot find -lxxx”是因为链接器ld未在指定路径中找到libxxx.so或libxxx.a，主因是搜索路径缺失、库名不匹配或缺少libxxx.so软链接；-l优先于library_path，再查系统默认路径；可用gcc -v查看search_dir确认实际搜索路径。
为什么gcc说“cannot find -lxxx”？
这不是源码写错了，而是链接器ld压根没在任何地方找到libxxx.so或libxxx.a。常见原因就三个：gcc根本没去你放库的目录找；它去了但名字对不上；或者库文件本身缺符号链接（比如只有libxxx.so.2.3，没有libxxx.so这个软链）。
-L和LIBRARY_PATH谁先起作用？
编译时，ld按固定顺序查库路径：
- 命令行里写的
-L/path/to/lib（最先） - 环境变量
LIBRARY_PATH里的路径（比如export LIBRARY_PATH=/opt/mylib:$LIBRARY_PATH） - 系统默认路径：
/usr/lib、/lib、/usr/local/lib（最后）
注意：LIBRARY_PATH只影响编译链接阶段，不影响程序运行；运行时靠的是LD_LIBRARY_PATH或/etc/ld.so.conf。
怎么确认gcc到底搜了哪些路径？
加-v参数让gcc吐出完整链接过程：
gcc -v test.c -L/opt/mylib -lmylib
输出里会有一段SEARCH_DIR列表，就是它实际查的路径。如果/opt/mylib没出现在里面，说明-L写错了位置（比如写在-l后面）、路径拼写错误，或被其他选项覆盖了。
另外，用which ld确认调用的是哪个链接器；用readelf -d a.out | grep 'NEEDED\|RPATH'看生成的可执行文件里硬编码了哪些运行时库路径。
静态库.a和动态库.so混用时容易漏什么？
同一个库如果同时有.a和.so，gcc默认优先连.so。如果你真要强制静态链接，得加-static-libgcc或-Wl,-Bstatic -lxxx -Wl,-Bdynamic这种显式控制。
更隐蔽的问题是：某些库（如libstdc++）在交叉编译时可能只提供了.a，但你的gcc配置默认关掉了静态链接支持——这时即使路径、名字都对，也会静默跳过.a，然后报cannot find -lxxx。检查方法是加-Wl,--verbose，看链接器日志里是否出现attempting static link字样。
真正麻烦的点在于：这些路径逻辑是分阶段生效的——编译时、链接时、运行时，各走各的路。改错一个地方，不代表问题消失；必须按阶段分别验证。
