Replace the loosely coordinated collection of x86 build arguments with
a single VARIANT selector. Define x64, x86, and multilib configuration
stages, then select the requested stage as the common cross-compiler
base. This keeps each supported configuration closed and prevents
callers from combining incompatible architecture settings.
Make x64 the default standalone profile. It targets
x86_64-w64-mingw32, disables GCC multilib support, builds only the
64-bit CRT, and omits the secondary 32-bit libraries and aliases.
Keep the standalone x86 behavior in its own profile. It targets
i686-w64-mingw32, retains the Pentium 4 default, enables only the
32-bit CRT, preserves the Windows XP header default and manifest
behavior, selects the 32-bit BusyBox and NSIS configurations, disables
zstd threading, and raises _WIN32_WINNT only while building CMake.
CMake and its bundled curl require at least Windows Vista APIs, so the
C and C++ flags continue to target Windows 7 without changing the
XP-oriented default of the installed toolchain.
Define multilib as an x86_64 compiler with GCC multilib enabled, both
CRT library sets installed, and the existing i686 forwarding aliases.
Use a dedicated EXTRA_32 setting for the secondary lib32 libraries,
winpthreads builds, thread support object, and aliases instead of
inferring that work from the spelling of a GCC configure option.
Expose independent CRT_LIB32 and CRT_LIB64 settings so each profile
selects exactly the runtime libraries it needs.
Pass the profile's CMake C and C++ flags directly rather than building
an optional argument list through shell positional parameters. Keep all
other profile-specific values next to the selected base stage, including
GCC architecture and manifest flags, BusyBox configuration, zstd
options, and NSIS target architecture.
Simplify multibuild.sh to pass only VARIANT to Docker. Add -m for the
multilib flavor, make -a build all three profiles, and remove the old
argument-file and Dockerfile-patch fallback paths. Update unsigned and
signed CI builds to select x64 or x86 directly, remove the obsolete
variant-x86.args bundle, and document the new build interface.
Verify all three profiles with docker build --check and complete cross
toolchain builds. Smoke-test x64 and x86 compilation, plus both the
64-bit compiler and i686 alias in the multilib profile. Also build the
x64 and x86 CMake targets to exercise both the empty and Windows 7
CMake flag configurations.
Keep x86_64 as the default output while enabling the GCC and mingw-w64
32-bit multilib under lib32. Build 32-bit support archives, CRT
libraries, and winpthreads for both the bootstrap and final sysroots so
each compiler stage has a complete i686 runtime.
Use pentium4 as the 32-bit architecture baseline. Add a GCC specs rule
that defaults _WIN32_WINNT to 0x0501 only under -m32 and only when the
caller has not supplied a value, preserving the existing x64 default and
explicit overrides.
Retain the x86_64-w64-mingw32-prefixed tools and add a separate build
step for an i686-w64-mingw32 interface. Compiler drivers inject -m32.
Target-sensitive binutils select their 32-bit modes explicitly: as uses
--32, ld uses -m i386pe, dlltool uses -m i386 with --as-flags=--32, and
windres uses --target=pe-i386. Input-driven inspection and archive tools
forward without a target override.
These forwarding executables provide both prefixed interfaces without
duplicating a second binutils installation. They deliberately remain
selectors for the underlying x86_64-configured multilib compiler rather
than spoofing its configured target identity.
Direct, Autoconf, CMake, and Libtool probes using the i686-prefixed
interface all produced PE-i386 output.
Adds aas-sign as a Windows binary in $PREFIX/bin/ so users can sign
their own PE outputs with Azure Trusted Signing from inside the
toolchain. Same source as build-aas-sign (the Linux helper used at
release time); on Windows aas-sign's CMakeLists uses WinHTTP + BCrypt
instead of mbedtls, so the build is self-contained.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds a CLI-only NSIS install for compiling .nsi scripts. Skips the
GUI wizards (makensisw, the NSIS installer creator) and documentation.
Path-resolution problem: makensis at $PREFIX/bin/makensis.exe would
auto-detect NSISDIR=$PREFIX (parent dir of bin), so NSIS would look
for $PREFIX/{Include,Stubs,Plugins,...} -- collides with w64devkit's
own $PREFIX/include on Windows's case-insensitive filesystem. Solve
by installing the real makensis under $PREFIX/share/nsis/bin/, where
auto-detection lands correctly on $PREFIX/share/nsis. A small alias
EXE at $PREFIX/bin/makensis.exe (built from the existing alias.c)
exec's it. Fully relocatable, no env vars.
New stages: dl-nsis, build-nsis. SCons + python3 only inside
build-nsis (not base) to avoid cache invalidation. TARGET_ARCH
derived from $ARCH at build time so the same Dockerfile works for
x64 and x86 -- no variant-x86.patch hunk needed.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
I wrote this new tool yesterday after reading about "cmake --debugger"
the night before, and it's already been powerful and useful. In the past
this would be a month-long project, but in 2026 it only takes a day.
By breaking independent parts of the build into stages breaks implied
dependencies between those parts. A tool built later will not require
rebuilding when earlier unrelated tools are changed. That includes
upgrades to require new downloads. Most tools can be upgraded without
requiring unnecessary rebuilds.
Go (gc toolchain) does not yet support bigobj, and so cgo is currently
incompatible with w64dk. Bootstrapping Go 1.4 from C still works, but
even that's increasingly impractical anyway.
UCRT is gradually growing in popularity, and it wasn't obvious from
README.md that w64devkit is a traditional MSVCRT toolchain.
The AVX issue comes up from time to time, just infrequently enough that
I need to rediscover the solution each time. Documentation in README.md
will be easier to find next time, warns those who haven't been bitten
yet, and documents the mitigation offline. Since it is unlikely to be
fixed any time soon, medium term I should figure out a small patch that
makes GCC only emit unaligned AVX moves. The penalty for unaligned moves
is 0% on newer processors and up to 10% on older ones. That's certainly
better than crashing due to a compilier bug.
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
Cuts the distribution size by around 60%, and unpacks around 100x faster
than Windows built-in .zip support. However, 7-zip is the worst packaged
project included so far. The source release is a tarbomb with a URL that
contains two variations of the release version. It is not designed for
cross-compilation, and so requires minor source corrections and a custom
build script. Still, considering the circumstances, it's surprising how
easily it compiles.
When I first put w64devkit together, there were incompatibilities with
Binutils and supporting gfortran was difficult. It's been stable for
years, and I want to simplify the download options.
I was initially impressed with its output, but over time I've found it
less and less useful. I hardly use it anymore, and it would at best be
neglected if left in the distribution. The build script is retained in
the contrib/ directory, and it's easy to build natively from source.
It's proven less useful than I originally hoped, and it's nearly always
better to use the GNU assembler instead. NASM doesn't support DWARF with
COFF, so it cannot be debugged with GDB. It's also ~100x slower than as,
which makes a huge different for generated assembly. With the autotools
fixes, it's now easy to natively build NASM from source using w64dk.
Provides 32-bit and 64-bit ___chkstk_ms and __chkstk. The former can
replace the libgcc implementation. Better license, about half the size,
and substantially faster when used on a hot path. The purpose and role
is similar to libmemory.
These new additions had not yet been documented, and are unlikely to be
discovered by chance. I dropped __USE_MINGW_ANSI_STDIO because now that
I've learned more I realized it has no practical use. If one cares about
this issue, one wouldn't use stdio in the first place, especially not
the particularly poor Microsoft stdio.
Despite appearances, the ">" operator is actually a pipe to Out-File,
and GetFileType() returns FILE_TYPE_PIPE for that handle. It is not
seekable and does not behave like a file. By default it re-encodes its
input, which is virtually always destructive, unwanted, and surprising.
Regardless of the wording in its documentation, it is not possible to
connect process output to a file, and PowerShell does not support file
redirection.
Cppcheck is a static analysis tool that's pretty easy to build and
include. Its "addons" are excluded since they depend on Python, as are
the "platforms" configuration since none of them are useful for Windows
applications. The "win32A" and "win32W" platforms are already embedded
within the tool.
It has a "FILESDIR" option to locate its configuration data. Relative
paths are unsupported, and so this feature is useless for a "portable"
Windows application. Fortunately it searches next to the executable, so
it can still find its configuration as long as it resides in the same
directory. These should not be in bin/, so build an alias to redirect
execution into share/.
This is yet another open source project that does not publish a stable
source tarball, so this build is likely to fail in the future when
GitHub changes its tarball layout. The --remote-header-name curl option
tells it to pick up the GitHub-provided name rather than use the request
path. Fortunately this doesn't seem to interfere with other downloads.
The "releases" section needs emphasis since GitHub doesn't give it good
visiblitiy, and lots of people seem to miss it. Also, in the time since
w64devkit came about, Mingw-w64 itself and other distributions have
improved, picking up features once unique to w64devkit. The previous
claims are less strong now.
Mingw-w64 v8.0.0 finally puts to rest the long-standing and irritating
issues with __USE_MINGW_ANSI_STDIO. As other distributions update they
will be on par with w64devkit on this point.
Msys2 supports optional static linking, and it does this well (though
optimized for speed, not size).
