C/C++混合编译链接报错：undefined reference问题排查及原因解析

这个问题的核心不是链接器本身的问题，也不是C/C目标文件不兼容，而是**C和C编译器的名字修饰规则差异**导致的，我来一步步拆解：

为什么重命名文件后错误消失？ #

当你把.c和.h改成.cpp和.hpp时，所有文件都会被G++（C编译器）编译。G会对所有函数名应用C++的名字修饰规则（比如把function()转换成_Z8functionv这类带参数信息的符号），此时main.cpp里调用的function()和AUX_IMU_functions.cpp里定义的function()的符号名完全匹配，链接自然就成功了。

而之前的场景中：

• AUX_IMU_functions.c被GCC（C编译器）编译，生成的符号是C风格的（比如_function，具体格式取决于ARM平台的ABI）；
• main.cpp被G编译，它会把header.h里的void function(void)当成C函数，所以链接时会寻找C++修饰后的符号，找不到C风格的符号就报了undefined reference。

还需要检查哪些内容？ #

如果不想把C文件改成C++文件，你需要做这些检查和修改：

• 给头文件添加C语言兼容声明
  这是C/C混合编译的标准解决方案：在header.h里用extern "C"包裹函数声明，让C编译器知道这个函数是按C规则编译的，不会对它应用C++名字修饰。修改后的头文件应该是这样：

  #ifdef __cplusplus
  extern "C" {
  #endif
  
  void function(void);
  
  #ifdef __cplusplus
  }
  #endif
  

  __cplusplus是C编译器自动定义的宏，这样写既兼容C编译器（会忽略extern "C"块），也能让C编译器正确识别函数的链接属性。

• 确认Makefile的编译规则正确
  检查你的Makefile，确保.c文件用arm-linux-gnueabihf-gcc编译，.cpp文件用arm-linux-gnueabihf-g++编译，不要用错编译器处理文件类型。比如：

  # C文件编译规则
  %.o: %.c
      arm-linux-gnueabihf-gcc -c $< -o $@
  
  # C++文件编译规则
  %.o: %.cpp
      arm-linux-gnueabihf-g++ -c $< -o $@
  

• 查看目标文件的符号表验证
  可以用ARM工具链里的nm命令查看两个目标文件的符号，确认符号名的差异：

  # 查看C编译生成的目标文件符号
  arm-linux-gnueabihf-nm ./src/FPGA_Peripherals/AUX_IMU/AUX_IMU_functions.o
  # 查看C++编译生成的main.o符号
  arm-linux-gnueabihf-nm ./src/main.o
  

  你会看到C生成的符号是T function（或者带下划线的T _function），而C++生成的引用是U _Z8functionv这类修饰后的名字，这就是链接失败的直接原因。

• 确认链接顺序正确
  虽然这个场景里不是主要问题，但链接器是按顺序处理目标文件的，确保定义函数的AUX_IMU_functions.o在调用它的main.o之前被指定给链接器，避免因为符号未提前定义导致的错误。

GCC C和GCC C++生成的.o目标文件是否不兼容？ #

完全兼容！两者生成的都是符合ARM ELF格式的目标文件，文件本身没有兼容性问题。问题只出在符号的命名规则上——C编译器用简单的符号名，C编译器为了支持重载、命名空间等特性，会对符号名进行复杂修饰。只要通过extern "C"统一符号的链接属性，C和C生成的目标文件可以完美一起链接。

内容的提问来源于stack exchange，提问作者new_stacker