lld不自动选择.a或.so，仅按-l顺序查找；必须用-bstatic/-bdynamic显式控制链接模式，或直接传静态库路径。
lld 默认按顺序解析 -l 参数，不区分静态/动态
lld（LLVM 的内置链接器）本身没有像 GNU ld 那样默认“优先找 .so、找不到再 fallback 到 .a”的逻辑。它只按命令行中 -l 出现的顺序，结合 -L 指定的路径，去查找匹配的库文件；但具体选 libxxx.a 还是 libxxx.so，取决于你是否显式控制链接模式。
也就是说：如果你只写 lld -L. -lfoo，而当前目录下同时有 libfoo.a 和 libfoo.so，lld 会报错——因为它不自动做选择，而是要求你明确指定类型或使用链接模式开关。
常见错误现象：ld.lld: error: unable to find library -lfoo，尤其在交叉编译或自定义工具链时，因为 lld 不读取系统默认库搜索逻辑（如 /usr/lib 下的隐式路径），也不 fallback。
- 必须用
-L显式提供所有库路径，不能依赖环境变量（LIBRARY_PATH对 lld 无效） - 如果只提供
-lfoo，lld 会尝试找libfoo.so（动态优先行为仅存在于部分发行版封装的clang调用链中，不是 lld 本体行为） - 要确保目标库文件真实存在且架构匹配（例如 aarch64 lld 无法链接 x86_64 的
.a）
用 -Bstatic / -Bdynamic 控制单个库的链接方式
lld 支持 GNU ld 兼容的 -Bstatic 和 -Bdynamic 开关，它们作用于其后所有 -l 参数，直到被下一个同类开关覆盖。这是混合链接的核心机制。
例如，你想静态链接 libmysqlclient.a，但动态链接 libz.so 和系统 libc.so：
ld.lld -o myapp main.o \ -L/usr/lib64/mysql -Bstatic -lmysqlclient -Bdynamic \ -L/usr/lib64 -lz -lc -lm
注意点：
-
-Bstatic和-Bdynamic必须直接传给 lld，不能只靠 clang wrapper；若用clang调用，需加-Wl,前缀：clang -Wl,-Bstatic -Wl,-lmysqlclient -Wl,-Bdynamic ... - 顺序敏感：一旦写了
-Bstatic，后续所有-l都走静态，除非被-Bdynamic中断 - 系统运行时库（如
libc、libm）强烈建议保持-Bdynamic，否则可能因缺少__libc_start_main等符号链接失败
绕过 -l 机制：直接传 .a 文件路径更可靠
当 -Bstatic -lxxx 仍失败（比如库名不标准、或存在多个变体如 libfoo_pic.a），最稳妥的方式是跳过 -l 查找逻辑，直接把静态库的完整路径作为输入文件传给 lld：
ld.lld -o myapp main.o \ /usr/lib64/mysql/libmysqlclient.a \ -L/usr/lib64 -lz -lc -lm
这样做的好处：
- 完全规避命名和搜索规则问题
- lld 把该
.a当作归档文件直接解包，逐个提取需要的目标文件（符合静态链接语义） - 不会影响后续
-l对动态库的解析
但要注意：直接传 .a 后，该库中未被引用的符号不会被拉入，而 -l + -Bstatic 可能触发整个归档的符号解析策略（取决于 lld 版本）。实践中前者更可控。
检查是否真用了静态链接：别信 file，要看 ldd 和 nm
file myapp 显示 dynamically linked 并不矛盾——只要程序依赖任何动态库（比如 libc.so），它就是动态链接可执行文件。静态链接的是“部分库”，不是整个程序。
验证 libmysqlclient 是否真的被静态嵌入：
- 运行
ldd myapp | grep mysql：如果无输出，说明没动态依赖它 - 运行
nm -C myapp | grep mysql_real_connect：如果能看到T（已定义）符号，说明函数代码已进入二进制 - 对比大小：静态链接
libmysqlclient.a通常增加 1–2 MB，而动态链接只加几 KB 的重定位信息
容易忽略的一点：lld 默认不保留静态库中的调试段（.debug_*），所以用 nm 看不到某些符号，不代表没链接上；应优先依赖 ldd 和实际运行测试。
