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.
Replace the windows-latest sign job (azure/login + azure/artifact-
signing-action) with a single Linux release job that uses
skeeto/aas-sign@v1.0.0. aas-sign handles the GitHub OIDC -> Azure
exchange directly, so the Azure CLI step is no longer needed and the
signed-artifact handoff to a separate release job collapses into one
step.
Also align the draft logic with sibling projects (dcmake, elfeed2,
stackcalc): tags vX.Y.Z-rcN are pipeline-test runs published as draft
prereleases; tags vX.Y.Z publish immediately.
archive: false makes upload-artifact override the user-supplied name:
parameter with the file's actual filename, so download-artifact can't
find artifacts named w64devkit-x64-unsigned, source-tarball, etc. Match
the artifact name to the filename so uploads and downloads agree.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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.
Now the clean target deletes this entire directory, so we can't miss
cleaning up vulkan related build artifacts. Previously, make -f
llama.mak clean would not remove
ggml/src/ggml-vulkan/vulkan-shaders/vulkan-shaders-gen.cpp.gen.o
Upstream commit 6990e2f1 changed common/build-info.cpp.in from just defining globals:
int LLAMA_BUILD_NUMBER = ...;
char const *LLAMA_COMMIT = ...;
to also defining functions:
int llama_build_number(void)
const char * llama_commit(void)
const char * llama_build_info(void)
To fix this, now we generate w64dk-build-info.cpp from the provided
common/build-info.cpp.in template.
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>
GitHub is going to remove node 20 from Actions:
https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
All the actions versions have been upgraded to the latest major versions
available, ahead of the Node 20 deprecation
Move Azure signing from the old Trusted Signing preview action to
Artifact Signing v1, update azure/login to v3, and bump
actions/download-artifact to v8.
Split release into sign (windows-latest, environment: release) and
release jobs. Signs both .7z.exe via Azure Trusted Signing before
attaching to the release. Tags starting with v publish; other tags
produce draft releases for testing the pipeline.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Rename release archives from .exe to .7z.exe. Build the new source
Docker target and produce a reproducible source.tar of all upstream
tarballs, attached as both a CI artifact and a release asset.
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.)
The breakpoint manager normalizes incoming setBreakpoints paths with
GetActualCaseForPath, but SourceFileLoaded and GetBreakpoints use
paths from CollapseFullPath, which preserves whatever case the caller
provided. On case-insensitive filesystems these can differ for the
same file, so the unordered_map keys do not match and breakpoints are
silently missed.
On macOS (HFS+) GetActualCaseForPath is a no-op, so the setBreakpoints
path passes through unmodified. If the DAP client sends "Test.cmake"
but cmake was invoked with "cmake -P test.cmake", the breakpoint is
stored under "Test.cmake" while GetBreakpoints looks up "test.cmake".
On Windows GetActualCaseForPath *does* normalize, but only in
HandleSetBreakpointsRequest. The breakpoint is stored under the
canonical "Test.cmake", while SourceFileLoaded and GetBreakpoints
still receive "test.cmake" from CollapseFullPath. The keys disagree
from the opposite direction.
Add a NormalizePath helper and apply it in all three public entry
points so that every map key goes through the same transformation.
On non-Windows it uses GetRealPath (wrapping realpath(3), which
returns the actual filesystem case on macOS and resolves symlinks on
Linux). On Windows the existing GetActualCaseForPath is retained.
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.
SHFileOperationWhas has a subtle, easy-to-misuse interface that does not
follow its own documentation. It says FO_DELETE skips relative paths,
but that's definitely not the case at least on some versions of Windows.
I rarely care about the status of the x86 builds, so this commit only
runs them if the x64 builds succeed. If the x64 build is successful but
the x86 build is not, the cache for the x64 build should kick in and the
x86 build should follow shortly after, if it's necessary to iterate on
it.
Updated the GitHub Actions workflow so x86 only runs after x64 succeeds.
Changed:
- Split the old matrix job into two explicit jobs: build-x64 and build-x86.
- Added needs: build-x64 on the x86 job, which enforces the dependency.
