C++调用C函数链接失败的根本原因是name mangling导致符号名不匹配；需用extern "C"声明函数声明（非定义）并正确包裹头文件，同时注意链接顺序与ABI限制。
为什么C++调用C函数时会链接失败
C++编译器默认对函数名做name mangling（名字修饰），比如void foo(int)可能被编译成_Z3fooi；而C编译器生成的是未修饰的符号名foo。链接器找不到匹配符号，就会报undefined reference to 'foo'这类错误。
根本原因不是语法不兼容，而是ABI层面的符号命名不一致。只要让C++编译器“别修饰这个函数名”，问题就解了一半。
extern "C"到底修饰什么、怎么写才有效
extern "C"不是函数声明，是链接规范说明符，作用对象是**函数声明或变量声明**，且只影响当前翻译单元中这些声明生成的符号。
常见写法误区：
立即学习“C语言免费学习笔记（深入）”；
- 只在C++文件里加
extern "C" { void foo(); }，但C头文件本身没做保护 → C文件包含该头时会报错（C不认extern "C"） - 把
extern "C"套在函数定义里（如extern "C" void foo() { ... }）→ 无效，必须作用于声明
正确做法：在C头文件中用宏包裹，兼顾C/C++双环境：
#ifndef MYLIB_H
#define MYLIB_H
#ifdef __cplusplus
extern "C" {
#endif
void c_function(int x);
int global_c_var;
#ifdef __cplusplus
}
#endif
#endif
混合编译时的链接顺序和库依赖陷阱
即使符号名对上了，链接仍可能失败——尤其是静态库场景。ld默认按命令行顺序解析符号依赖：
-
g++ main.cpp -lmyc -o app：如果main.cpp里调用了c_function，但libmyc.a在命令行靠后，链接器扫到main.o时还不知道c_function在哪定义 → 报undefined -
解决方法：把依赖库放被依赖目标之后，或用
-Wl,--no-as-needed（谨慎），或拆成两次链接
动态库（.so）相对宽松，但要注意运行时LD_LIBRARY_PATH是否包含C库路径，否则./app启动直接error while loading shared libraries。
extern "C"不能解决的所有问题
extern "C"只管符号名，不管语义和ABI细节：
- C++异常穿过C函数边界 → 未定义行为。C函数里千万别
throw，C++调用方也别指望在C函数里catch - C结构体含C++成员（如
std::string）→ C代码根本没法读写，extern "C"也救不了 - 函数指针类型混用：C函数指针
void (*f)(int)和C++重载后的同签名指针，在二进制层面可能不同（尤其涉及thiscall）
真正安全的混合接口，应该用纯C风格设计：只传POD类型、避免引用/重载/模板、错误用返回码不用异常。extern "C"只是让这条路能走通的第一步，不是万能胶。
