Skip to content

2026.8.25.2 — one predicate family, closed - #506

Merged
Sunrisepeak merged 2 commits into
mainfrom
fix/a-freestanding-pin-is-a-capability-not-a-convention
Aug 25, 2026
Merged

2026.8.25.2 — one predicate family, closed#506
Sunrisepeak merged 2 commits into
mainfrom
fix/a-freestanding-pin-is-a-capability-not-a-convention

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

A package declaring which layer it supplies moved a bare-metal RISC-V build onto the host's g++.

provides = ["mcpp:kernel-abi=openkal"]
$ mcpp build --target riscv64-none-elf
  Resolved gcc@16.1.0 → riscv64-none-elf → …/bin/g++
  g++: error: unrecognized argument in option '-mabi=lp64d'
  g++: error: unrecognized command-line option '--target=riscv64-none-elf'

graphSuppliesSystem spans kernel-abi ∪ c-abi and cancels the target row's compiler pin. Correct for a hosted row — it names the payload supplying that target's C library, and a graph supplying one instead makes it inapplicable. Wrong for a bare-metal row, which names the only compiler that can emit the target: a host g++ cannot produce riscv64-none-elf whatever the graph contains.

Fifth defect of the shape 2026.8.25.1 fixed four of. Found by re-pinning the seven downstream CIs after that release; openkal-opensbi failed on the same line under 2026.8.24.6, so this predates both releases.

e2e 292 asserts both directions — never cancelling the pin also passes half one, and would restore the substitution the predicate exists to prevent. Verified to fail against the previous binary.

Declaring which layer a package supplies moved a bare-metal RISC-V build
onto the host's g++. Three lines of manifest reproduce it:

    provides = ["mcpp:kernel-abi=openkal"]

    $ mcpp build --target riscv64-none-elf
      Resolved gcc@16.1.0 → riscv64-none-elf → …/bin/g++
      g++: error: unrecognized argument in option '-mabi=lp64d'
      g++: error: unrecognized command-line option '--target=riscv64-none-elf'

`graphSuppliesSystem` spans kernel-abi ∪ c-abi and cancels the target row's
compiler pin. For a hosted row that is correct: the row names the payload
that supplies the target's C library, and a graph supplying one instead
makes it inapplicable — that substitution is what the predicate was added
to prevent. A bare-metal row names something else, and the table says so in
its own words: "the pin is llvm on every host because clang/lld are
cross-compilers by construction". A host g++ cannot emit riscv64-none-elf
whatever the graph contains.

The two kinds of pin are now distinguished, and the distinction is recorded
at the same read that takes the pin rather than re-derived at the decision
point.

Fifth defect of the shape 2026.8.25.1 fixed four of: a predicate spanning
two layers deciding something that depends on neither. Found by re-pinning
the seven downstream CIs after that release — openkal-opensbi failed on
this, and had failed on the same line under 2026.8.24.6, so it is a
survivor of that span rather than anything either release introduced.

e2e 292 asserts both directions: never cancelling the pin also makes half
one pass, and would restore the substitution.
@Sunrisepeak Sunrisepeak changed the title 2026.8.25.2 — a freestanding pin is a capability, not a convention 2026.8.25.2 — one predicate family, closed Aug 25, 2026
@Sunrisepeak
Sunrisepeak force-pushed the fix/a-freestanding-pin-is-a-capability-not-a-convention branch 5 times, most recently from da51b22 to 93c88d1 Compare August 25, 2026 12:48
`2026.8.25.1` fixed four defects that share one shape: a predicate spanning
kernel-abi ∪ c-abi deciding something that depends on neither. This closes
the remaining three, adds the reporting side, and fills the two CI holes
that let them survive. Analysis:
`.agents/docs/2026-08-25-the-two-layer-predicate-family.md`.

⑤ A package naming which layer it supplies moved a bare-metal RISC-V build
   onto the host's g++ — three lines of manifest reproduce it. A hosted
   row's pin is a convention (which payload supplies the C library); a
   bare-metal row's is a capability (which compiler emits the target at
   all). The two are now distinguished at the same read that takes the pin.

⑥ `Target x86_64-windows-gnu → x86_64-unknown-linux-gnu` — two operating
   systems on one line, no diagnostic, and Windows sources compiled for
   Linux. The report already held the evidence; this asserts on it. Scope
   is the OS only: the vendor/spelling difference is the normalisation that
   line reports, and refusing on it would reject every correct cross build.

⑦ The macOS branch adds `-isysroot` and its own comment says why ("ld64.lld
   dies with library not found for -lSystem"); the graph branch 80 lines
   below replaced the whole link line and discarded it. Linux needs no
   equivalent because its kernel interface is an instruction; Darwin's IS a
   library, so a Mach-O link needs the SDK whoever supplies libc.
   `platformAnchor` is written once and read once.

+ `toolchain list` filtered on "has a payload" and presented it as "can be
  built". `x86_64-windows-musl` was absent on a host that produces real
  PE32+ artefacts for it. Third status: `via dependency graph`. What a
  graph cannot supply — MSVC, the macOS SDK — stays out.

+ The mirror completeness gate failed a release twice on one transient 502
  for an asset it held (verified by hand: 5,772,395 bytes, matching
  sha256). Both verification GETs retry with `--retry-all-errors`.

Tests: e2e 292/293/294, each asserting both directions and each verified to
fail against the pre-fix binary. 285-289 had never run in CI — they declare
`# requires: llvm` and neither linux shard has it — so `ecosystem-e2e` now
installs the capabilities, runs all nine directly, and asserts each PASS
line, plus the run-phase lines of 287/288 which degrade to SKIP silently.
@Sunrisepeak
Sunrisepeak force-pushed the fix/a-freestanding-pin-is-a-capability-not-a-convention branch from 93c88d1 to ce98762 Compare August 25, 2026 13:41
@Sunrisepeak
Sunrisepeak merged commit d35c043 into main Aug 25, 2026
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants