Set requirements for windows-gnu

[mati865]

Proposal

Currently, there are no declared minimal versions for tools used with windows-gnu targets. When somebody has problem with their old tooling, it's usually recommended to try with what Rust uses on the CI, which is nontrivial to figure out (FYI, it's https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0). This translates to:

• GCC 14.1.0
• Binutils 2.42
• mingw-w64 12.0.0

Settling on the minimal versions for the tools will be hard because there are numbers of recent fixes that would benefit Rust, so I'll list notable fixes and corresponding Binutils version which is the most important component to us (because it's the most troublesome):

• GNU linker warns “corrupt .drectve” on staticlib binary generated with Rust 1.70 on Windows rust#112368 - tens of thousands of warnings when linking; fixed by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=37513c1efbe5e8e1863f8ddf078cd395aa663388 and shipped in Binutils 2.40
• removing dlltool and thus solving all related issues (notably with this fix ld.bfd can use LLD made import libs). There are many related fixes there:
  • https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b53b12c8e86bb30003f7dd644638db770127e689 - Binutils 2.40
  • https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=46bbc1c071ca5ceb1d6cfcd38e65eef28f27283c - Binutils 2.40
  • https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b7eab2a9d4f4e92692daf14b09fc95ca11b72e30 - Binutils 2.41
  • issue details in https://sourceware.org/bugzilla/show_bug.cgi?id=30079 and [binutils] internal error aborting msys2/MINGW-packages#15469
• enabling native TLS - it wasn't done previously in Rust because the binaries were crashing. GCC 16 landed support for native TLS and hit the same Binutils bugs as we did previously. Notable fixes:
  • https://sourceware.org/bugzilla/show_bug.cgi?id=31092 - Binutils 2.44
  • more fixes that supposedly happened during 2.43-2.44 but I didn't bother checking whole commit history
  • more details in GCC's bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881, TL;DR Binutils >=2.44 should be fine
• enabling function sections - no fix in sight, a somewhat related discussion: https://sourceware.org/pipermail/binutils/2025-December/146255.html

Versioning of other components isn't as much important to Rust:

• mingw-w64 provides headers, libs and objects enabling use of Windows built-in libraries, so you typically want to always use latest version (many toolchains use latest trunk); with raw-dylib this has become much less important
• GCC provides unwind library and C/C++ compiler, we'd be fine with whatever can build our dependencies like LLVM

Toolchains available in the open:

Details

• MSYS2 (Windows native):
  • GCC 16.1
  • Binutils 2.46
  • mingw-w64 trunk
• mingw-w64-builds (Windows native):
  • GCC 16.1
  • Binutils 2.46
  • mingw-w64 14.0.0
• w64devkit (Windows native):
  • GCC 16.1
  • Binutils 2.46
  • mingw-w64 14.0.0
• Arch Linux:
  • GCC 16.1
  • Binutils 2.46
  • mingw-w64 14.0.0
• Debian stable:
  • GCC 14.2
  • Binutils 2.43.1
  • mingw-w64 12.0.0
• Debian testing/unstable:
  • GCC 15.2
  • Binutils 2.45
  • mingw-w64 14.0.0
• Fedora 42:
  • GCC 14.2
  • Binutils 2.43.1
  • mingw-w64 12.0.0
• Fedora 43:
  • GCC 15.2
  • Binutils 2.45.1
  • mingw-w64 13.0.0
• Fedora 44:
  • GCC 16.1
  • Binutils 2.46
  • mingw-w64 13.0.0
• Ubuntu 24.04 LTS:
  • GCC 13.2
  • Binutils 2.41
  • mingw-w64 11.0.1
• Ubuntu 26.04 LTS:
  • GCC 13.2
  • Binutils 2.45
  • mingw-w64 13.0.0
• cross-rs
  • GCC 9.3/9.4 (x86_64/i686)
  • Binutils 2.34
  • mingw-w64 7.0.0

I hope that we can figure out in the discussion (using a poll?) which version should we make as the baseline. Personally I'd like if we could make it Binutils 2.44 and enable native TLS (as a subsequent work), but this might be a hot take.

Additional thing to consider

Since mingw-w64 12.0.0, UCRT is the default CRT library, but the distributions tend to conservatively keep MSVCRT as the default (except Arch Linux), and provide UCRT as a separate package. UCRT is recommended by MSYS2 and more popular choice at mingw-w64-builds when comparing download counts.
If'd feel like a missed opportunity if we went with this MCP and remained stuck at MSVCRT.

How it works?

Mingw-w64 provides three libs:

• libmsvcrt-os.a - Windows MSVCRT import lib
• libucrt.a - Windows UCRT import lib
• libmsvcrt.a - UCRT with mingw-w64 12, unless configured otherwise

GCC, Clang and rustc all link the CRT via -lmsvcrt, so the binary will use whatever the toolchain uses by default. There is a caveat however, mixing different CRTs is nontrivial and should be avoided unless use knows what they're doing.
While Rust's artifacts so far work with both MSVCRT and UCRT toolchains, making UCRT the default one could save us headaches in the future.

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (1 active)

• exact-minimums

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[jieyouxu]

I like the general premise of having some kind of documented minimum
@rustbot second

[jieyouxu]

... but like discussed, we should figure out precisely which
@rustbot concern exact-minimums