llvm本身不负责链接第三方库，实际由clang（前端）或lld（链接器）在调用时完成；需在clang命令中显式添加-i指定头文件路径、-l指定库路径、-l指定库名，且-l必须置于源文件之后，顺序需符合依赖关系。
LLVM 本身不负责链接第三方库——那是 Clang（前端）或 LLD（链接器）的事，但你必须在调用 clang 时显式指定，而不是在 LLVM 构建阶段配置。
clang 命令里怎么加 -l 和 -L 参数
LLVM 编译流程中，“链接第三方库”实际发生在 clang 调用阶段。Clang 是 LLVM 的 C/C++ 前端，它会把源码编译成 bitcode 或目标文件，再调用链接器（默认是系统 ld，或你指定的 lld）完成链接。
常见错误是以为在 CMake 配置 LLVM 时加 -DLLVM_ENABLE_PROJECTS="clang" 就能自动链接任意第三方库——完全不能。那只是让构建系统产出 clang 可执行文件而已。
-
-L/path/to/lib：告诉链接器去哪找库文件（注意路径必须存在，且包含libxxx.a或libxxx.so） -
-lxxx：链接名为libxxx.a或libxxx.so的库（-lssl→ 找libssl.a） - 顺序重要：
-l必须放在源文件或目标文件之后，否则链接器可能忽略未解析符号 - 如果第三方库有依赖（比如
libfoo依赖libz），要按依赖顺序写：-lfoo -lz，不能反过来
示例命令：
clang main.c -L/opt/mylib -lmyutil -o myapp
这等价于让 Clang 后端调用 lld（若已启用）或系统 ld，并传入对应参数。
用 LLD 替换系统链接器时要注意什么
LLVM 自带的 lld 是轻量、快速的链接器，但行为和 GNU ld 不完全一致，尤其对第三方库路径处理更严格。
- 确保
lld已随 LLVM 安装（构建时加了-DLLVM_ENABLE_PROJECTS="lld"） - 显式启用：
clang -fuse-ld=lld -L/path -lxxx main.c；不加-fuse-ld=lld时，Clang 默认用系统ld -
lld不自动搜索/usr/local/lib等非标准路径，必须用-L明确指定 - 静态链接时，
lld对 archive（.a）内符号解析更严格，若第三方.a未按需导出所有符号，可能报undefined reference
第三方库头文件找不到？那是 include 路径问题
链接失败常被误判为“库没连上”，其实八成是编译阶段就卡在头文件：fatal error: 'xxx.h' file not found。
-
-I/path/to/include才是告诉 Clang 去哪找头文件，和-L完全无关 - 头文件路径和库路径通常成对出现，但必须分别指定：
clang -I/opt/mylib/include -L/opt/mylib/lib -lmyutil main.c - 若库使用 pkg-config，优先用：
clang $(pkg-config --cflags --libs mylib) main.c，避免手写路径出错 - Clang 不读取
CPATH或LIBRARY_PATH环境变量，这些是 GCC 的习惯，LLVM 工具链不认
自己编译的 LLVM/Clang 找不到 libc++ 或 libstdc++
这不是第三方库问题，而是标准库路径未正确注入。Clang 构建时不会硬编码标准库位置，运行时靠内置规则或显式参数定位。
- Linux 上默认找系统
libstdc++，macOS 上找libc++；若你用libc++但系统没装，会报cannot find -lc++ - 指定标准库：
clang -stdlib=libc++ main.cpp（需提前装好libc++开发包） - 自定义安装路径的标准库：用
--sysroot=/path/to/sysroot或-resource-dir=/path/to/clang/lib/clang/18.1.0（版本号要匹配） - 最稳妥方式：用
clang++而不是clang编译 C++ 代码，它会自动带标准库链接参数
真正容易被忽略的是：Clang 的链接行为高度依赖你调用它的具体命令行，而不是 LLVM 源码怎么编译的。哪怕你从头编译了全套 llvm-project，只要没在 clang 命令里写对 -I、-L、-l，第三方库就纹丝不动。
