The split GCC package set (`gccNGPackages`, opted into with `useGccNG`)
builds each runtime library separately, so the compiler is configured
independently of `libgcc` and `libstdc++` and the two can disagree about
threading. Rather than probe the compiler, those packages read the answer
from the package that decides it, through the same `passthru.threadModel`
that `glibc`, `musl` and NetBSD's `libc` already declare.
MinGW's libc has none of its own beyond the Win32 API, so it declares
`win32`. Past that the answer depends on which threading library a
toolchain is built against, so `mcfgthreads` declares `mcf` and
`winpthreads` `posix`. Nothing reads either yet.
The headers-only build is marked as such rather than given a model: it
exists only to get the libc compiled, and runtimes built against it stay
single-threaded.
Assisted-by: Claude Code (Claude Opus 5)
Previously we relied on the default CRT selected by upstream. This
broke builds against MSVCRT starting with 12.0, as the default was
changed to UCRT
We can instead manually configure the CRT based on our `stdenv` to
ensure there is no discrepancy between the CRT we want to use and that
being targeted by the build
This is the most upstream one, and so to avoid infinite recursion we
should get the things from it. This isn't needed per-se now, but will be
after the next commit.
(cherry picked from commit 4bd76beac0)
This is the most upstream one, and so to avoid infinite recursion we
should get the things from it. This isn't needed per-se now, but will be
after the next commit.
Version 6.0.0 brings better Win32 API coverage and bugfixes.
It's been used in various distros long enough to be considered stable.
Latest version 7.0.0 hasn't received extensive testing yet.
Announce mail:
https://sourceforge.net/p/mingw-w64/mailman/message/36416777/
