Repository navigation
CMake 4.3.4, GCC 16.2.0, Clang 23 - #31
Merged
Merged
Conversation
ednolan
force-pushed
the
enolan_clang23_1
branch
from
August 30, 2026 01:49
e387bf6 to
840a81a
Compare
ednolan
changed the title
Switch the arm64 base image from arm64-llvm-openrc to arm64-openrc. The LLVM-profile stage3 points portage at the .../23.0/arm64_llvm binhost, which carries ~400 packages (clang 22 and gcc 15.3.0 only); the default profile uses .../23.0/arm64 with ~10000, covering clang 17-22 and gcc 14-15. Recategorise accordingly: - clang 17.0.6-r1, 18.1.8-r7 and 19.1.7-r1 are now cached on arm64, so they join testing_ci.yml's arm64 matrix and clang 19.1.7-r1 leaves fromsource_ci.yml entirely. - gcc 11.5.0, 12.5.0 and 13.4.1_p20260603 are cached on amd64 but not on arm64. Their amd64 leg was in testing_ci.yml and their arm64 leg in fromsource_ci.yml, so both files' merge jobs created the :11/:12/:13 tags from a single arch's digest and whichever ran last won. Move them wholly into fromsource_ci.yml; Dockerfile.fromsource still honours the binhost, so the amd64 legs keep pulling the binpkgs. - Drop stale clang 17.0.6-r1 and 18.1.8-r7 entries from fromsource_ci.yml's merge matrix; no build job in that workflow produced them. Also replace the =dev-lang/python-3.12.12 pin in Dockerfile.test with the :3.12 slot. That version has been dropped from the tree, which would have broken the clang 17 build on both arches. Refresh README.md: the published tag list was stale (GCC 16.1.0/15.2.1, Clang 22.1.6, no Clang 23) and it still advertised CMake 4.2.1. Also mention gcovr and vcpkg, which the images have shipped for a while. Fix three bugs in Dockerfile.test's Clang package.mask block, which left portage free to resolve LLVM components to a major that the same block masks. This surfaced as a hard failure for Clang 17 and 18 on arm64: - llvm-runtimes/libcxx and libcxxabi were not masked at all, so portage preferred the newest libcxx, which depends on a masked llvm slot. - llvm-core/llvmgold was masked only under `uname -m == x86_64`. It is keyworded ~arm64, so on arm64 it could resolve to a masked slot as well. - The clang-runtime mask named llvm-core/clang-runtime, which does not exist. The package is llvm-runtimes/clang-runtime, so that line masked nothing. amd64 survived with only the libcxx route open because portage backtracks out of it; arm64 had two open routes and gave up, which is why Clang 19-22 pass there and 17-18 do not. Verified with `emerge -p` for Clang 17 and 18 on both stage3 images: every LLVM component now pins to the matching major. Sync the ebuild tree with `emerge --sync` (rsync) rather than `emerge-webrsync`. webrsync fetches the daily snapshot, which lags the tree by up to 24 hours; the rsync mirrors regenerate roughly every 30 minutes. Clang 23.1.0 landed in the tree at 07:30 UTC and the snapshot in use that evening had been cut at 00:48 UTC, so `=llvm-core/clang-23.1.0` had no ebuild to match. Measured on amd64: `emerge --sync` takes about 52-58s against 16s for `emerge-webrsync`, which is noise next to an 8-90 minute image build. rsync is already present in the stage3, so this needs no repos.conf changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ednolan
force-pushed
the
enolan_clang23_1
branch
from
August 30, 2026 03:01
840a81a to
b19542e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switch the arm64 base image from arm64-llvm-openrc to arm64-openrc. The LLVM-profile stage3 points portage at the .../23.0/arm64_llvm binhost, which carries ~400 packages (clang 22 and gcc 15.3.0 only); the default profile uses .../23.0/arm64 with ~10000, covering clang 17-22 and gcc 14-15.
Recategorise accordingly:
clang 17.0.6-r1, 18.1.8-r7 and 19.1.7-r1 are now cached on arm64, so they join testing_ci.yml's arm64 matrix and clang 19.1.7-r1 leaves fromsource_ci.yml entirely.
gcc 11.5.0, 12.5.0 and 13.4.1_p20260603 are cached on amd64 but not on arm64. Their amd64 leg was in testing_ci.yml and their arm64 leg in fromsource_ci.yml, so both files' merge jobs created the :11/:12/:13 tags from a single arch's digest and whichever ran last won. Move them wholly into fromsource_ci.yml; Dockerfile.fromsource still honours the binhost, so the amd64 legs keep pulling the binpkgs.
Drop stale clang 17.0.6-r1 and 18.1.8-r7 entries from fromsource_ci.yml's merge matrix; no build job in that workflow produced them.
Also replace the =dev-lang/python-3.12.12 pin in Dockerfile.test with the :3.12 slot. That version has been dropped from the tree, which would have broken the clang 17 build on both arches.
Refresh README.md: the published tag list was stale (GCC 16.1.0/15.2.1, Clang 22.1.6, no Clang 23) and it still advertised CMake 4.2.1. Also mention gcovr and vcpkg, which the images have shipped for a while.