Windows下GCC编译静态库生成.o而非.lib的原因及链接问题咨询

问题背景 #

在Windows系统中使用GCC 8.1.0（通过安装Code::Blocks并配置环境变量添加gcc.exe路径部署环境），使用Visual Studio内置编辑器编写代码，通过Visual Studio的PowerShell执行编译操作：

• 库开发目录下有mul.c和mul.h文件，执行编译命令gcc -c mul.c后生成mul.o目标文件而非mul.lib静态库文件，需手动指定-o mul.lib才能生成预期扩展名的文件。
• 将头文件、.lib文件与main.c放在同一父目录后，可通过gcc main.c -I./include -L/static -lmul -o my_program.exe生成可执行文件。

疑问 #

1. 为何在Windows环境下GCC会生成.o文件而非.lib？
2. 参考Linux下编译静态库的教程，将库命名为libmul.o时，-lmul选项可正常找到库，但将生成的静态库命名为libmul.lib时出现如下链接错误：

C:/Program Files/CodeBlocks/MinGW/bin/../lib/gcc/x86_64-w64-ingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmul
collect2.exe: error: ld returned 1 exit status

请问这些是GCC的正常行为，还是仅通过配置环境变量导致的副作用？

解答 #

疑问1解答：GCC生成.o而非.lib的原因 #

这是GCC的正常行为，和环境变量配置无关。gcc -c命令的核心作用是编译单个源文件，生成目标文件（.o格式）——这是编译过程的中间产物，仅包含当前源文件编译后的机器码，未完成跨文件的链接处理。

静态库（.lib/.a）是多个目标文件的打包产物，在MinGW环境下，正确生成静态库的流程是：

1. 先用gcc -c mul.c生成mul.o目标文件
2. 再通过ar rcs mul.lib mul.o命令将目标文件打包为真正的静态库

你手动指定-o mul.lib只是修改了目标文件的扩展名，本质上它还是单个目标文件，并非标准静态库。

疑问2解答：libmul.lib无法被-lmul找到的原因 #

这同样是GCC的正常行为，与环境变量无关。MinGW作为Windows平台的GNU工具链实现，遵循GNU链接器的库查找规则，同时兼容部分Windows平台特性：

• 当使用-lxxx选项时，链接器会按以下优先级查找库文件：
  1. 优先搜索libxxx.a（GNU标准静态库扩展名）
  2. 若找不到，会尝试搜索xxx.lib（Windows平台常见的静态库格式，无lib前缀）
• 你将库命名为libmul.lib，链接器执行-lmul时会查找libmul.a或mul.lib，自然无法匹配到libmul.lib；而命名为libmul.o时，链接器会将其视为可直接链接的目标文件，因此能正常识别。

若想通过-lmul找到静态库，可采用两种方式：

1. 将库重命名为mul.lib，匹配-lmul的查找规则
2. 直接在编译命令中指定库文件路径，如：gcc main.c -I./include -L/static libmul.lib -o my_program.exe

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