为何Windows版g++默认静态链接C++标准库而Linux默认动态链接？

不同平台默认链接行为差异的核心原因 #

两边默认行为不一致和GCC上游本身无关，是不同发行版的预设配置差异、平台生态惯例共同导致的：

• Debian系统仓库打包的GCC 11.3.0严格遵循Linux桌面/服务器生态的通用规则：C++标准库libstdc++、C运行库libc都是系统级预装的基础组件，动态链接既可以大幅缩减单程序体积，还能让多个运行中的程序共享库的内存页，降低整体内存占用，也不存在依赖缺失问题，因此默认配置就是动态链接标准库。你不加参数编译出25KB可执行文件是完全正常的动态链接产物。
• 你在Windows上使用的是TDM64社区打包的GCC 10.3.0，并非GCC官方直接发布的二进制。Windows系统本身不会预装MinGW/TDM体系的libstdc++动态运行库，如果默认开启动态链接，普通用户编译出的exe拷贝到没有安装对应TDM运行时的机器上会直接报找不到dll的启动错误。TDM的维护者为了降低普通用户的使用门槛，特意将默认链接配置修改为静态链接libstdc++和libgcc，会把标准库中用到的代码全部打包进单个exe文件，这就是你不加参数得到3026KB大体积exe的根本原因。
• 你追加的--shared-libstdc++参数本质是手动覆盖了TDM-GCC的默认配置，强制切回动态链接模式，此时exe仅包含自身代码和启动引导逻辑，运行时依赖Path路径下的libstdc++-6.dll、libgcc_s_seh-1.dll等运行时文件，体积自然降到290KB。剩余和Linux版本的体积差来自Windows PE可执行格式与Linux ELF格式的结构差异、平台启动引导代码的区别，属于正常范围。

关于“Windows动态链接libstdc++存在已知缺陷”的误解 #

这个默认静态链接的选择纯粹是发行版维护者的用户体验取舍，不存在技术层面的已知缺陷迫使GCC必须在Windows上默认静态链接：

• 两种链接模式都是Windows平台GCC长期支持的成熟配置，各有适用场景：
  • 静态链接的优势是生成单exe文件，拷贝到同架构Windows机器上就能直接运行，不需要附带额外依赖文件；劣势是程序体积更大，如果进程中加载了多个分别静态链接不同版本libstdc的dll模块，跨模块传递C对象（比如在一个模块new对象、另一个模块delete）时容易触发内存错误。
  • 动态链接的优势是单程序体积小，多个使用同版本运行时的程序可以共享dll内存；劣势是分发程序时必须把对应版本的运行时dll一起打包，否则目标机器无法启动程序。
• 其他常见的Windows GCC发行版（比如原生MinGW-w64构建）很多默认就是动态链接libstdc++，和Linux行为一致，也侧面证明默认值只是打包方的选择，和平台缺陷、GCC上游设计无关。

补充验证方式 #

你可以在两个平台编译时都加上-v参数输出完整的编译链接命令行，就能直观看到Windows下TDM-GCC默认隐式加了-static-libstdc++ -static-libgcc参数，而Debian的GCC默认没有添加这两个静态链接参数。另外两边一个大版本的版本差（10.3 vs 11.3）对可执行文件体积的影响非常小，不是造成体积差的主要原因。

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