Clang静态库导出C接口必须用extern "C"：头文件需用#ifdef __cplusplus包裹extern "C" { }声明所有供C调用的函数，实现文件（.cpp）中不可添加extern "C"；编译仍用clang++，链接C端须用gcc/clang而非g++，并通过nm验证符号为my_init而非_Z7my_initi。
Clang静态库导出C接口必须用 extern "C"
Clang编译的静态库（.a 文件）若要被C代码链接，必须确保符号不经过C++名称修饰（name mangling）。否则C端调用时会报 undefined reference to 'xxx' —— 这不是链接路径问题，而是符号名根本对不上。
关键点：只在头文件中用 extern "C" 声明，且必须包裹所有供C调用的函数声明；实现文件（.cpp）里不需要、也不应该加。
- 头文件（如
mylib.h）开头和结尾用条件宏包裹：#ifdef __cplusplus extern "C" { #endif <p>void my_init(int cfg); int my_process(const char* data, size_t len);</p><h1>ifdef __cplusplus</h1><p>}</p><h1>endif - 如果头文件被纯C项目包含，
__cplusplus宏未定义，extern "C"部分自动跳过，完全兼容 - 不要在
.cpp实现里写extern "C" void my_init(...) { ... }—— 这会导致链接器看到两个不同签名的符号，或引发ODR违规
Clang编译静态库时不用额外加 -x c 或改后缀
静态库本身只是目标文件（.o）的打包，不决定符号类型。真正影响符号的是源码中函数声明的方式，以及编译时对每个源文件的处理方式。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
常见误区：把 .cpp 文件改成 .c 后缀，或用 clang -x c 强制当C编译——这会让C++实现代码直接报错（比如用了 std::vector），得不偿失。
- 保持
.cpp后缀，用C++实现逻辑，只通过头文件暴露C接口 - 编译时仍用
clang++（不是clang），确保C++标准库可用 - 生成静态库命令不变：
ar rcs libmylib.a mylib.o
链接时C端必须用 gcc 或 clang（不能用 g++ 默认链接）
即使静态库是用 clang++ 编译的，只要头文件正确用了 extern "C"，C程序用 gcc 链接完全没问题。但若误用 g++ 链接C主程序，它会悄悄链接C++运行时（libstdc++），而你的静态库又没依赖它——表面能连上，运行时可能崩在 __cxa_atexit 之类符号缺失。
- C主程序编译命令应为：
gcc main.c -L. -lmylib -o main - 验证符号是否导出为C风格：
nm libmylib.a | grep my_init，看到的是T my_init（不是T _Z7my_initi）才对 - 如果C端也用
clang，同样不要加--std=c++17等C++参数
头文件被C++项目包含时，extern "C" 不影响内部实现
同一个头文件既要给C用，也要给C++项目用（比如做跨语言SDK），上面的条件宏写法已足够。但要注意：C++项目包含该头文件后，调用这些函数仍是C链接约定，函数体内仍可自由使用C++特性。
-
my_init()在.cpp里可以 new 对象、调用模板函数、用std::string—— 只要头文件声明是C风格 - 别在头文件里写
extern "C" { #include <vector> }—— C不认std::vector，预处理器不会帮你过滤 - 如果头文件里需要内联函数或模板，它们必须放在
extern "C"块外，否则编译失败
C接口兼容这事，核心就卡在头文件那几行 extern "C" 宏包裹是否干净、彻底。漏掉一个函数声明，或者实现文件里多写了一个 extern "C"，都可能导致某个函数在C侧永远找不到。
