这是C++符号修饰导致的链接错误：g++将void foo(int)编译为_Z3fooi，而C代码未用extern "C"声明，造成调用方找foo、提供方只供_Z3fooi。
为什么 g++ 编译的函数在 ld 链接时报 undefined reference to '_Z3fooi'
这是 C++ 符号修饰（Name Mangling）最典型的外显症状：你写了 void foo(int)，但链接器看到的不是 foo，而是类似 _Z3fooi 这种“加密”后的名字。C++ 允许多重载、命名空间、模板等特性，编译器必须把函数签名信息编码进符号名，否则链接器无法区分 void foo(int) 和 void foo(double)。
常见错误现象：
- 用
extern "C"声明了函数，但定义时没加，或只加在头文件里、忘了在 .cpp 里也加 - C 代码调用 C++ 函数时，直接写
foo(42)，而没用extern "C"声明 - 用
nm或objdump -t查看目标文件，发现符号名和预期完全对不上
怎么让 C++ 函数导出为 C 风格符号（禁用 mangling）
核心就是用 extern "C" 把函数“包起来”，告诉编译器：“这段按 C 的规则生成符号，不加修饰”。它不是关键字，是 linkage specification，只影响符号名生成方式，不影响类型检查或运行逻辑。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 头文件中声明时，用
#ifdef __cplusplus包一层：#ifdef __cplusplus extern "C" { #endif void my_util_func(int x); #ifdef __cplusplus } #endif - 定义（.cpp 文件）里也必须加
extern "C"，否则声明和定义的 mangling 不一致，链接仍失败 - 不能对类成员函数、模板函数、重载函数使用
extern "C"—— 它们天然依赖 mangling，硬加会编译报错 - 如果只在单个 .cpp 里定义且只供 C 调用，可直接在定义前加：
extern "C" void legacy_api() { /* ... */ }
如何查一个符号到底被 mangling 成了什么
别猜，直接看。Linux/macOS 下用 c++filt 反解，或用 nm 结合 --demangle：
-
nm my.o | c++filt—— 显示可读函数签名 -
nm -C my.o（-C等价于--demangle） - Windows MSVC 用
dumpbin /symbols，输出里带???开头的就是 mangled 名；可用undname工具反解 - 注意：
nm默认不显示 static 函数，加-a才能看到所有符号
参数差异：不同编译器 mangling 规则不同 —— g++ 用 Itanium ABI（LLVM/Clang 也沿用），MSVC 自有一套。跨编译器混用目标文件基本不可行。
链接时提示 undefined reference to 'foo' 但 nm 显示有 _Z3fooi，怎么办
说明调用方（比如 C 代码）在找未修饰的 foo，而提供方（C++ 目标文件）只提供了 mangled 的 _Z3fooi。这不是符号没定义，是“叫法不统一”。
关键检查点：
- 确认调用方是否真的用了
extern "C"声明 —— 少一个引号、多一个分号都会失效 - 确认头文件是否被 C 和 C++ 源文件都正确包含（尤其注意
#include路径和预处理器宏） - 确认链接顺序：提供符号的目标文件（.o）必须出现在依赖它的目标文件之后，比如
gcc main.c libcpp.o -o app，不能反过来 - 如果用
libtool或构建系统（CMake/Makefile），确保.cpp文件被g++编译，而不是误用gcc（后者不触发 C++ mangling 规则，但也不认识extern "C"块里的 C++ 语法）
最容易被忽略的是：同一个头文件，在 C 编译单元里被当作 C 解析，在 C++ 编译单元里被当作 C++ 解析 —— 如果没用 __cplusplus 宏做条件包裹，extern "C" 在 C 编译下会报错，而在 C++ 编译下又可能漏掉。
