Sign every PE inside the toolchain (~250 .exe and .dll), pack, then
sign the resulting self-extracting archive. All signing runs at
docker run time so the bulk of the build remains fully cacheable
and secrets never enter image layers.
Stage layout:
- dl-aas-sign / build-aas-sign: SHA-pinned source tarball with
vendored mbedtls + nlohmann/json, built with the base image's
Debian gcc.
- final: assembly only (drop the trailing 7z + CMD).
- signed (new): COPY aas-sign + sign-and-pack.sh, CMD runs the
script at docker run time. Reads AZURE_CLIENT_ID/TENANT_ID and
the GitHub OIDC env vars from -e flags.
- pack (new, default target): RUN 7z + CMD cat sfx archive.
Behaviorally identical to the old final.
The release workflow rebuilds --target signed for each arch
(reusing the same GHA cache scope as the unsigned pack build),
then docker runs the image to produce the signed package on
stdout.
Bumps GCC from 15.2.0 and adjusts the build for the new release:
- Drop the obsolete stdcall-align patch, no longer needed.
- Configure with --enable-tls so libstdc++ uses native Windows TLS
rather than emutls. This is an ABI break: object files built with
earlier w64devkit releases cannot be linked against new builds.
- Import gcc-dynamic-load-tzdb.patch (originally from
redpanda-cpp/mingw-lite, by CyanoHao) so that libstdc++'s C++20
std::chrono::current_zone() Windows backend resolves
GetDynamicTimeZoneInformation at runtime via LoadLibrary/
GetProcAddress. Without this, _WIN32_WINNT < 0x0600 builds fail
to compile tzdb.cc.
- Add gcc-libgfortran-mapview.patch to replace the new
MapViewOfFileExNuma call in libgfortran's caf_shmem with
MapViewOfFileEx, which mingw-w64 declares for older Windows
targets. NUMA_NO_PREFERRED_NODE makes the two calls equivalent,
so no functional change.
dcmake now sets _WIN32_WINNT internally, so drop the matching
define from variant-x86.patch for the dcmake build.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds an optional "source" Docker target that collects all upstream
source tarballs for producing a source.tar release artifact. BuildKit
skips it unless explicitly requested via --target source.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
In DepsLog::Load(), the file offset used for truncation-based recovery
was advanced past each record immediately after reading its bytes from
disk, but before validating the record's semantic correctness (e.g. the
path checksum or node-id range checks). When a record was structurally
complete but semantically invalid, recovery truncated the file to an
offset that included the bad record, so it was never removed.
This created an infinite cycle: every build would load the deps log, hit
the corrupt record, "recover" by truncating everything after it (but not
the record itself), then append new dependency records that would be
destroyed by the next build's recovery. The result was spurious rebuilds
on every invocation.
Move the offset update to the end of the loop body, after all validation
has passed. Now when a record fails validation, the offset still points
before it, and truncation correctly removes it.
(This patch has been submitted upstream.)
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.
Aliases remain small because size is important and they are already
maximum speed. The distribution is ~10MB (~22%) larger, but C++ builds
with this toolchain are ~25% faster.
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.
The official Vim project no longer hosts older versions of Vim, and the
original Vim host is now gone. Due to the hashes, we can safely download
from anywhere stable, so let's try this mirror.
