extern "C"本质上只干一件事：关闭 C++ 的名称修饰，让函数导出的符号名保持与 C 一致，这样链接阶段才能准确匹配。

但在头文件里，extern "C"代码块必须放进 #ifdef __cplusplus 条件包装中。否则一旦交给 C 编译器处理，就会直接报错。

还要注意，光做到这一步还不够。只有再配合 C 兼容的数据类型以及 visibility 属性，跨语言调用这件事才算真正打通。

extern "C" 必须加在头文件里，且只对 C++ 编译器生效

如果正在编写一个需要同时给 C 和 C++ 项目使用的动态库头文件，那么 extern "C" 绝不是什么“可加可不加”的修饰。它本质上是链接阶段必须明确写清楚的声明。

它的作用很直接：告诉 C++ 编译器，这一段函数名不要做 name mangling，保持标准的 C 风格符号名。

也就是说，像 init_config 这样的函数，最终导出的就还是 init_config，而不会变成 _Z12init_configv 这类 C++ 风格的符号。

需要特别留意的是，extern "C" 对 C 编译器本身并不起作用。因为 C 标准压根不认识这套语法，所以外面必须再用预处理器条件包一层。

• 错误写法：extern "C" { void foo(); } 直接放在 .h 里 → C 编译器报错 error: expected identifier or '(' before string literal
• 正确写法：用 #ifdef __cplusplus 包裹，确保 C 编译器跳过 extern "C"
• 常见疏漏：只在 .cpp 实现文件里加 extern "C" → 头文件暴露的声明仍被 C++ mangling，C 端链接时找不到符号

动态库导出函数必须同时满足 C linkage 和可见性规则

仅加 extern "C" 不足以让函数被外部 C 程序调用。

GCC 默认编译的 shared library 中，函数符号默认是全局可见的。但若用了 -fvisibility=hidden（推荐做法），就必须显式标记导出。

• C++ 实现文件中，函数定义前要加 extern "C"，且需配合 visibility 属性：extern "C" __attribute__((visibility("default"))) int load_config(const char* path);
• 更稳妥的做法是在头文件中统一定义宏：#define EXPORT_API extern "C" __attribute__((visibility("default")))，然后声明为 EXPORT_API int load_config(const char* path);
• 不加 visibility("default") 时，即使 nm -D libxxx.so 看不到该符号，C 端 dlsym 会返回 NULL，错误信息是 undefined symbol: load_config

头文件里不能混用 C++ 类型，否则 C 端无法解析

extern "C" 只解决符号名问题，不解决类型兼容。C 编译器不认识 std::string、引用、重载、模板等任何 C++ 特性。

• 错误示例：extern "C" { void log_message(std::string msg); } → C 文件包含此头文件直接编译失败
• 正确做法：参数和返回值必须是 C 兼容类型——基本类型、struct（不含成员函数/虚表）、const char*、指针；如需传递字符串，用 const char* 或带长度的 const uint8_t*
• 结构体若含 C++ 成员（如 std::vector），必须拆成纯 C 结构 + 独立操作函数，例如：typedef struct { int* data; size_t len; } IntArray;，再配 extern "C" IntArray* make_int_array(size_t n);

验证是否真正兼容：用 nm 和 objdump 看符号，用 C 程序实测 dlsym

别信“编译过了就 OK”。很多问题只在链接或运行时暴露。

• 检查符号：编译后执行 nm -D libmylib.so | grep init_config，应看到 T init_config（不是 U 或带下划线前缀/后缀的乱码）
• 检查 ABI：用 objdump -t libmylib.so | grep init_config，确认 type 是 FUNC 且 binding 是 GLOBAL
• 最硬核验证：写一个极简 C 文件，#include ，void* h = dlopen("./libmylib.so", RTLD_LAZY);，void (*f)() = dlsym(h, "init_config");，运行看是否 segfault 或 f 为 NULL

一个容易被忽略的问题

最容易被忽略的是：C++ 实现里调用了 STL 或其他 C++ 运行时函数，比如 std::cout，会导致 C 程序加载时因缺失 libstdc++.so 而失败。

也就是说，哪怕头文件完全 C 兼容，动态库本身也依赖 C++ ABI。

《夸克》非常好用的免费AI浏览器

下载APP查看