lld链接时静态库函数“消失”是因为其默认按需提取归档成员，未被显式引用的.o文件被丢弃；而GNU ld更宽容，可能隐式展开部分归档内容。
为什么 lld 链接时静态库里的函数“消失了”
不是函数没编译进去，而是 lld（尤其是启用 --gc-sections 或默认 aggressive 模式时）在链接阶段直接丢弃了未被显式引用的静态库成员。GCC 的 ld 默认行为更“宽容”，而 lld 更激进——它只拉取真正被符号引用触发的目标文件（.o），且不自动展开整个 .a 归档。如果你的 main.c 没有直接调用 libmath.a 中某个 .o 里的任何符号，那个 .o 就不会进入最终可执行文件。
lld 链接静态库必须加 --whole-archive 吗
不一定，但得看你怎么用。以下情况需要干预：
- 你依赖的是“间接引用”：比如通过函数指针、
dlsym、或运行时注册表（如插件系统）调用函数，lld在静态链接期根本看不到这些引用 - 你用了构造函数（
__attribute__((constructor))）或全局对象初始化，而它们所在的.o没被其他符号拉进来 - 你期望整个
.a被无条件包含（例如做固件打包、MCU 初始化段合并）
此时才需 -Wl,--whole-archive -lmath -Wl,--no-whole-archive。注意：这个开关只对紧邻其后的库生效，不能写成 -Wl,--whole-archive -lmath -lother——-lother 也会被 whole-archive 包裹，除非显式关掉。
怎么确认某个符号到底有没有进最终二进制
别猜，直接查：
- 用
nm -C your_executable | grep 'your_symbol'看是否出现在最终符号表里 - 用
llvm-objdump -t your_executable | grep 'your_symbol'查符号类型和绑定（UND表示未定义，GLOBAL DEFAULT表示已定义并驻留） - 反向验证库本身：用
llvm-ar -t libmath.a列出所有成员.o，再用llvm-nm -C math_util.o | grep 'add'确认符号确实存在于源.o中
如果 nm 在可执行文件里找不到，但在 .o 里存在，基本就是链接器根本没拉这个 .o 进来。
lld 和 ld 在静态库处理上的关键差异
核心区别不在“能不能”，而在“默认要不要”。lld 默认按 ELF 规范严格执行“按需提取（member extraction）”，而传统 ld（尤其是 GNU ld 的某些版本）在某些配置下会隐式展开部分归档内容，造成行为不一致。
-
lld不支持--undefined强制引入符号（GNU ld 支持），替代方案是加一个 dummy 引用：extern void force_link_add(void); void *dummy = (void*)force_link_add; -
lld对归档内重复符号更严格，遇到多个.o定义同一全局符号会直接报错，而ld可能静默选第一个 - 交叉编译场景下，
lld对.a中目标架构检查更早、更硬性——若file libmath.a显示是aarch64，而你链接的是x86_64可执行文件，lld会在解析阶段就拒绝，不等走到重定位
最易被忽略的一点：LLVM 工具链中，clang 调用 lld 时默认开启 --icf=all（identical code folding），它可能把看似不同但机器码相同的函数合并，导致你调试时找不到预期符号——这不是链接失败，而是优化副作用，必要时加 -Wl,--icf=none 关掉。
