The Minimalist Gnu for Windows distribution comes with support for
the traditional msvcrt libc, as well as ucrt64 libc. The latter
being the newer universal compiler runtime. We follow the msys2
environment naming convention[1]:
| name | toolchain | arch | libc | libc++ |
|------------|-----------|---------|--------|-----------|
| mingw32 | gcc | i686 | msvcrt | libstdc++ |
| mingw64 | gcc | x86_64 | msvcrt | libstdc++ |
| ucrt64 | gcc | x86_64 | ucrt | libstdc++ |
| clang32 | llvm | i686 | ucrt | libc++ |
| clang64 | llvm | x86_64 | ucrt | libc++ |
| clangarm64 | llvm | aarch64 | ucrt | libc++ |
For now nixpkgs only supports the first three with this commit.
--
[1]: https://www.msys2.org/docs/environments/
Without the change build frequently fails on `gnumake-4.4` as:
x86_64-w64-mingw32-dlltool: cannot delete libmsvcr120d_defs02133.o: No such file or directory
x86_64-w64-mingw32-dlltool: cannot delete libmsvcr120d_defs02134.o: No such file or directory
Pull upstream patches that fix temporary file collisions and add
missing dll dependencies.
With 0507725 "setup-hooks/strip.sh: run RANLIB on static
archives after stripping" it should now be safe to run strip
on wider range of .a files.
mingw-w64 is a good example where a reference was preserved
to gcc from intermediate stage. Enabling stripping by default
decreases `pkgsCross.mingw32` closure for 20%:
Before:
$ nix path-info -rsSh $(nix-build -A pkgsCross.mingw32.stdenv)
...
/nix/store/qzhkidff0wxhqf2gi97ng6qismzvpnbp-stdenv-linux 43.6K 1.0G
After:
$ nix path-info -rsSh $(nix-build -A pkgsCross.mingw32.stdenv)
...
/nix/store/fj4dv1n3sa3jgcb1j3nwn6njsf943n48-stdenv-linux 43.6K 792.4M
Fixes the evaluation of packages in pkgs/os-specific/windows that
weren't updated to include a new lib parameter after the refactor from
stdenv.lib -> lib (#109490).
I originally only intended this change to fix
`pkgsCross.mingw32.buildPackages.gcc` & `pkgsCross.mingwW64.buildPackages.gcc`
to support building wine with `mingwSupport`, but I noticed this was
an issue for all updated windows packages. Most of these other
packages fail to build for other reasons.
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/
Without this, a `#include <float.h>` resolves incorrectly. Either the
headers weren't on the include path at all, or they only were for
local, not system, imports.
What's weird is this used to not be a problem. Not sure what other
change in e.g. cc-wrapper would affect this.
See previous commit for what was done to `binutils` to make this
possible.
There were some uses of `forcedNativePackages` added. The
combination of overrides with that attribute is highly spooky: it's
often important that if an overridden package comes from it, the
replaced arguments for that package come from it. Long term this
package set and all the spookiness should be gone and irrelevant:
"Move along, nothing to see here!"
No hashes should be changed with this commit
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The winpthreads library is part of the same source package, so let's
just override the name and the source directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
