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.
Hoist every variant-sensitive value into an ARG at the top of the cross
stage, with defaults producing the x64 kit, and gate the multilib-only
sidecar builds on MULTILIB. The x86 variant becomes a set of NAME=value
overrides in src/variant-x86.args, which multibuild.sh turns into
--build-arg options. A plain "docker build" continues to work untouched,
downloads stay shared between variants, and the patch mechanism remains
available as a fallback for a future variant needing structural changes.
One hazard of this approach: ARGs leak into the environment of every
subsequent RUN in the stage, and configure scripts read arbitrary
environment variables. mingw-w64-crt decides whether to build the Win64
runtime by testing whether a shell variable named LIB64 is merely set,
so an ARG of that name forced lib64 on past an explicit --disable-lib64.
Hence CRT_LIB64. Keep ARG names clear of names configure might consult.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
After the growth of various dependencies, the added weight of a C++
toolchain has become relatively small. I no longer feel it's worth
including as a separate variant.
As of GDB 13.1, gdb.exe contains data triggering a bug in x64 Explorer
zip integration at last as far back as Windows 7. After recompressing
with advzip, gdb.exe extraction fails with 0x80004005 "Unspecified
error". This happens with both 32-bit and 64-bit gdb.exe regardless of
compiler flags. No other zip program has trouble with this file.
Until this is resolved, give up on advzip and tell zip to use -9. Also
renamed the build script option from -q (quick) to -O (optimize) and
disable its use by default.
