register openkal-musl 0.19.0 - #453
Merged
Merged
Conversation
`bits/setjmp.h` --- the INSTALLED header that sizes `jmp_buf` by the target's calling convention --- reads `__MCPP_TARGET_WINDOWS__`, mcpp's own name for the fact, and keeps `|| defined(__CYGWIN__)` beside it. TWO OPERANDS COVER EVERY ENGINE AND THE ORDER OF RELEASES DOES NOT MATTER. An engine up to and including 2026.9.21.1 defines the borrowed name, which answers; the release that withdraws it defines mcpp's own, which answers instead. There is no engine that defines neither, so this header has no flag day. The borrowed name was costing four members of the compatibility measurement, each reading `__CYGWIN__` as "Win32 is available" and reaching `#include <windows.h>`. Withdrawing it from the engine requires this release to be PUBLISHED FIRST: measured on the engine branch that withdraws it, building an openkal program for `x86_64-windows-gnu` against the published 0.18.0 fails on libunwind's two `static_assert`s. No source of musl itself changed. Registration only; nothing is re-pinned onto it by this change.
`Lint platform version parity` is the check that caught it: the descriptor carries `linux`, `macosx\' and `windows` tables and a version registered in one of them is a package that resolves on one host and not on the others. 27 versions in each.
Sunrisepeak
added a commit
that referenced
this pull request
Sep 20, 2026
`__libunwind_config.h` --- the INSTALLED header that sizes `unw_context_t` by the target's register save area --- reads `__MCPP_TARGET_WINDOWS__` and keeps `|| defined(__CYGWIN__)` beside it. Two operands cover every engine, so the order of releases does not matter. A SIXTH PATCH SITE, FOUND BY ENUMERATING RATHER THAN BY FAILING: `compiler-rt/lib/builtins/int_lib.h`. That file is not installed, so it takes a package-private define (`OPENKAL_TARGET_WINDOWS`) instead of the engine's name --- the distinction is whose compile reads the header, which is the same distinction that decides whether a macro belongs to the engine at all. Pins openkal-musl 0.19.0, registered in #453, which carries the matching change to `bits/setjmp.h`. Cross-verified against the mcpp branch that withdraws `__CYGWIN__`: five jobs green, including the Windows-host row of `host-dimension`, which builds `x86_64-windows-gnu` and resolved `openkal-musl@0.19.0`. That row is the one that matters here, since the macro exists only on Windows targets.
Sunrisepeak
added a commit
that referenced
this pull request
Sep 20, 2026
THE TWO MOVE TOGETHER BECAUSE THE MEASUREMENT IS ABOUT WHAT THE PAIR DOES. The engine withdraws `__CYGWIN__`. Four members of this suite --- archive (xz), sqlite3, mimalloc, c-ares --- stopped at `#include <windows.h>` reached through `#if defined(_WIN32) || defined(__CYGWIN__)`, and upstream means "Win32 is available" by that name. THIS MEASUREMENT IS THE CRITERION FOR THAT CHANGE: the `windows.h` group should reach zero, and nothing that ran before should stop running. `runtime` -> 0.15.0 is what keeps the withdrawal safe. It pins openkal-musl 0.19.0, and both read `__MCPP_TARGET_WINDOWS__` in the INSTALLED headers that size `jmp_buf` and `unw_context_t`, keeping `|| defined(__CYGWIN__)` beside it. Measured on the engine branch before it merged: against the PUBLISHED 0.13.0, an openkal program for x86_64-windows-gnu fails on libunwind's two `static_assert`s. Registered and published first --- #453, #455, #456 --- before this line moved. 0.15.0 also makes `thread_local` destructors run, which `doctest` and `spdlog` stop on today with `undefined symbol: __cxa_thread_atexit`. Those two are the other half of what this run should report. `openkal-compat.yml`'s MCPP_VERSION moves with `pins.toml` because that workflow checks the two agree. `latest_mcpp` moves; `min_mcpp` DOES NOT --- this release adds no manifest key, so no client loses the index.
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.
bits/setjmp.h--- the INSTALLED header that sizesjmp_bufby the target'scalling convention --- reads
__MCPP_TARGET_WINDOWS__, mcpp's own name forthe fact, and keeps
|| defined(__CYGWIN__)beside it.TWO OPERANDS COVER EVERY ENGINE AND THE ORDER OF RELEASES DOES NOT MATTER. An
engine up to and including 2026.9.21.1 defines the borrowed name, which
answers; the release that withdraws it defines mcpp's own, which answers
instead. There is no engine that defines neither, so this header has no flag
day.
The borrowed name was costing four members of the compatibility measurement,
each reading
__CYGWIN__as "Win32 is available" and reaching#include <windows.h>. Withdrawing it from the engine requires this releaseto be PUBLISHED FIRST: measured on the engine branch that withdraws it,
building an openkal program for
x86_64-windows-gnuagainst the published0.18.0 fails on libunwind's two
static_asserts.No source of musl itself changed. Registration only; nothing is re-pinned
onto it by this change.