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>
Shea Levy