Problem on generating gcm.cache/std.gcm on Windows using gcc version 15.2.0

by

Summary

This incident centers on GCC 15.2.0 failing to generate std.gcm on Windows due to internal‑linkage symbols inside MinGW’s C headers being re‑exported by bits/std.cc. The compiler correctly rejects this because C++ modules cannot export entities that lack external linkage. The failure is not a user error but a toolchain integration defect.

Root Cause

The underlying issue is that MinGW’s C library headers declare several functions with internal linkage, and GCC’s std module implementation attempts to re‑export them.

Key points:

  • MinGW’s wchar.h marks functions like wprintf, wscanf, vwscanf with internal linkage.
  • GCC’s std module (bits/std.cc) tries to export using std::wprintf; and similar.
  • C++ module rules forbid exporting anything that does not have external linkage.
  • GCC therefore emits errors such as:
    • “exporting ‘int wprintf(…)’ that does not have external linkage”

This is a toolchain mismatch, not a mistake in your command.

Why This Happens in Real Systems

This class of failure is common when C++ modules interact with legacy C headers:

  • C libraries often use macros, inline functions, or internal‑linkage declarations for ABI reasons.
  • C++ modules require strict, well‑defined linkage for anything exported.
  • Windows toolchains (especially MinGW) have inconsistent header implementations compared to Linux glibc.
  • GCC’s C++20 module support is still evolving, and MinGW is not a primary test target.

In short: modules demand discipline that old C headers were never designed for.

Real-World Impact

These issues cause:

  • Failure to build the standard module (std)
  • Inability to use C++20/23 modules on Windows with MinGW
  • Broken or incomplete module caches (gcm.cache)
  • Developers losing time debugging errors that are not their fault

Teams relying on modules for build acceleration or encapsulation often hit these roadblocks.

Example or Code (if necessary and relevant)

Below is a minimal reproduction showing why exporting an internal‑linkage symbol is illegal:

// bad.cc
static int f();   // internal linkage
export module bad;
export using ::f; // ERROR: cannot export internal-linkage entity

This mirrors the MinGW/GCC failure.

How Senior Engineers Fix It

Experienced engineers approach this by fixing the toolchain, not the code:

  • Avoid MinGW for C++20/23 modules until its headers are updated.
  • Use MSYS2 + Clang or MSVC where module support is stable.
  • On GCC, use Linux where the libstdc++ headers match GCC’s module expectations.
  • Track GCC bug reports; many MinGW module issues are already filed.
  • Patch the headers locally only as a last resort:
    • Replace internal‑linkage declarations with external ones (dangerous and unsupported).
  • Prefer prebuilt toolchains known to support modules.

The professional fix is: use a toolchain where modules are officially supported.

Why Juniors Miss It

Less‑experienced engineers often assume:

  • The compiler is always correct for all platforms.
  • MinGW behaves like Linux GCC.
  • Errors about linkage are caused by their code, not the system headers.
  • Modules “just work” because they are part of the standard.

They rarely suspect:

  • Header-level ABI quirks
  • Toolchain fragmentation on Windows
  • Incomplete module support in GCC for non‑Linux environments

Senior engineers recognize these patterns immediately because they’ve seen toolchain integration failures many times before.

Leave a Comment