clang编译目标文件必须加-c参数生成.o，再用ar rcs命令归档为.a静态库；需确保.o含全局符号、ar加s参数建索引，并用nm验证符号存在，跨平台需匹配ABI与架构。

clang 编译目标文件时必须加 -c 参数

直接用 clang 源文件名会默认生成可执行文件，不是静态库需要的目标文件（.o）。不加 -c 会导致后续归档失败或链接时报“undefined reference”——因为没生成符号表完整的 .o。

• clang -c file.c -o file.o 是必须步骤，-c 表示只编译不链接
• 多个源文件要分别编译成 .o，不能一次把所有 .c 一起传给 clang -c（它会为每个输入生成对应 .o，但容易漏写 -o 或命名冲突）
• 如果用了头文件或宏定义，记得加上 -I 和 -D 参数，否则 .o 里可能缺失依赖符号

用 ar 命令打包成 .a 文件

clang 本身不生成静态库，得靠系统工具 ar 把 .o 文件归档。常见错误是误用 clang -shared（那是生成动态库）或漏掉 r 标志导致归档失败。

Clang 22.1.3

Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。

下载

• ar rcs libmylib.a file1.o file2.o：其中 r 表示插入或替换，c 表示创建新库（静默），s 表示生成索引（必须，否则链接器找不到符号）
• 顺序无关，但建议先检查 .o 是否真实存在：file file1.o 应输出 “ELF … relocatable”
• 如果提示 ar: bad format，大概率是某个 .o 是空文件或编译失败残留，删掉重编

验证静态库是否可用

生成完不能直接认为搞定，很多问题在链接阶段才暴露。最简验证方式是写一个最小 main.c 调用其中函数，再用 clang 链接。

• clang main.c -L. -lmylib -o test：注意 -L. 指定当前目录为库路径，-lmylib 对应 libmylib.a
• 若报错 undefined reference to 'xxx'，先用 ar -t libmylib.a 看 .o 是否真在里面；再用 nm -C libmylib.a | grep xxx 查符号是否存在且未被 strip
• 如果函数是 static 的，不会导出到 .a 中——静态库只打包全局符号，这点和实现细节强相关

跨平台兼容性要注意 ABI 和架构

用 clang 在 macOS 上生成的 .a，默认是 Mach-O 格式；Linux 上是 ELF；Windows 上需用 llvm-ar 或第三方工具。同一份源码在不同系统上不能混用 .a 文件。

• macOS 上 ar 实际是 libtool 的包装，有时需显式用 llvm-ar 保证格式一致
• 交叉编译时，必须用对应 target 的 clang（如 aarch64-linux-gnu-clang）和配套 ar，否则 .o 架构不匹配
• 静态库不含运行时信息，但依赖的 libc 版本、调用约定（如 x86_64 vs i386）必须和最终链接目标一致

实际项目里最容易卡在符号可见性和 ar 索引缺失上，尤其多人协作时有人忘了加 s 参数，或者头文件里声明了函数但 .c 里没实现——这些都不会在归档时报错，只会在下游链接时突然崩。