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 标志导致归档失败。
-
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 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
-
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 里没实现——这些都不会在归档时报错，只会在下游链接时突然崩。
