LLD链接时提示“cannot find -lxxx”说明LLD在链接阶段未找到libxxx.so或libxxx.a文件，它不读LD_LIBRARY_PATH，只认-L参数、LIBRARY_PATH环境变量和系统默认路径；需确认库存在、命名合规（如libxxx.so软链接）、路径显式指定且顺序正确，并确保架构匹配。
LLD链接时提示“cannot find -lxxx”说明什么
这表示LLD在链接阶段压根没找到libxxx.so或libxxx.a文件，和运行时报error while loading shared libraries是两回事。LLD不读LD_LIBRARY_PATH，只认三类路径：-L参数、LIBRARY_PATH环境变量、系统默认路径（如/usr/lib）。常见误操作是改了LD_LIBRARY_PATH却指望它能救编译失败。
确认库文件是否存在且命名合规
LLD按固定规则匹配：-lxxx → 查找libxxx.so（优先）、libxxx.a、libxxx.so.X。如果只有libxxx.so.2.1但没软链接libxxx.so，就会失败。
- 用
find /usr/lib /usr/local/lib -name "libxxx*"查真实路径 - 用
ls -l /path/to/libxxx.so*看有没有指向具体版本的libxxx.so软链接 - 没有就手动建：
sudo ln -sf libxxx.so.2.1 /usr/lib/libxxx.so - 第三方库若在
./deps/lib下，别只写-lxxx，得加-L./deps/lib
检查LLD是否被正确调用及路径顺序
LLD是LLVM的链接器，但GCC/Clang默认可能仍用GNU ld。确认实际调用的是LLD：
- 编译时显式指定：
clang++ -fuse-ld=lld ...或gcc -fuse-ld=lld ... -
-L必须出现在对应-l之前，比如clang++ main.o -L./lib -lxxx -o app，反过来会失败 - LLD对路径更严格，某些GNU ld容忍的相对路径（如
-L../lib）在LLD里可能失效，建议用绝对路径 - 如果用CMake，确保
set(CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld")生效，并检查VERBOSE=1输出确认命令行含-fuse-ld=lld
静态库与架构兼容性常被忽略
LLD默认优先找动态库，但如果只有libxxx.a，它也能用——前提是架构匹配。很多“找不到库”的本质是架构错配。
- 用
file libxxx.a确认是x86_64还是aarch64，和你的目标平台一致吗 - 交叉编译时，库路径不能混用宿主机和目标机的
/usr/lib - LLVM 14+对
libfl.a/libl.a这类Lex相关库更敏感，若报-ll失败，先查libfl.a是否存在，再建软链接：ln -s libfl.a /usr/lib/libl.a - 某些发行版（如Ubuntu）把开发库拆到
libxxx-dev包里，仅装libxxx1不行，必须sudo apt install libxxx-dev
最容易漏掉的是：LLD不继承GNU ld的某些隐式搜索逻辑，比如对/usr/lib/x86_64-linux-gnu这种多架构子目录的自动探测。如果你的库真在那里，就得显式-L/usr/lib/x86_64-linux-gnu，不能依赖“默认”。
