为何GCC与MSVC编译的C目标文件无法相互链接？

核心结论 #

C的ABI确实由操作系统/平台规范定义，但Windows平台上MSVC与GCC（MinGW系列）的C实现细节存在差异，导致直接链接目标文件会出错——这并非C没有稳定ABI，而是不同编译器套件对Windows ABI的实现有细微分歧，且初始化逻辑、链接指令格式不兼容。

链接错误的具体原因 #

1. 初始化代码差异
   MSVC与GCC的C程序初始化逻辑不同：GCC编译的目标文件会依赖__main函数完成全局变量初始化等工作，但MSVC工具链中不存在该符号，因此用MSVC链接器链接GCC生成的gccF.o时会报unresolved external symbol '__main'。

2. 链接指令格式不兼容
   MSVC生成的.obj文件包含drectve段（链接器指令），GCC链接器对该段的解析格式与MSVC不一致，因此会出现Warning: corrupt .drectve at end of def file的警告。

3. 无效的编译选项
   -mabi=ms是ARM平台的专属选项，x86-64架构下完全无效，自然无法解决跨编译器链接问题。

跨编译器链接的可行方案 #

如果必须在MSVC和GCC之间共享C代码，最可靠的方式是通过**动态链接库（DLL）**实现：

1. 修改头文件，添加导出/导入标记：

   // msvcF.h
   #ifdef _MSC_VER
   #define API __declspec(dllexport)
   #else
   #define API __declspec(dllimport)
   #endif
   API void test();
   

2. 用MSVC编译生成DLL：

   cl /LD msvcF.c  # 生成msvcF.dll和msvcF.lib
   

3. 用GCC编译并链接DLL的导入库：

   gcc gccF.c msvcF.lib
   

   执行上述步骤后即可正常调用MSVC编译的test函数。

关于C兼容性的意义 #

C的ABI兼容性价值体现在：

• 同一平台/ABI规范内的跨编译器兼容：比如Linux下的GCC、Clang、ICC都严格遵循SystemV AMD64 ABI，跨编译器链接目标文件完全没问题；
• 跨语言交互的通用层：几乎所有编程语言（Python、Java、Rust等）都支持调用遵循平台C ABI的动态库，C成为不同语言之间互操作的“桥梁”；
• Windows平台的特殊情况可通过DLL规范规避——只要遵循微软的DLL导出标准，无论用什么编译器生成的C代码，都能被其他工具链调用。

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