You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(toolchain): Apple is one answer for both of its platforms, and two sites asked it differently
THE TIER MOVE EXPOSED TWO DEFECTS, ONE ON EACH SIDE OF THE SAME QUESTION.
While the iOS rows were `planned` neither could be seen: `toolchain list` keeps
a planned row unconditionally, so the listing was right by accident on every
host. Measured as `scan (macos-arm64)` and `scan (linux-aarch64)` reaching
three fewer cells than the expected table declares.
`host_can_serve` ASKED `os == "macos"`. That was the same question as "is this
an Apple target" while macOS was the only Apple target mcpp had. An iOS target
fell through to the function's final `return false` -- on EVERY host, including
the one that serves it. The consequence was not a refused build, because the
SDK gate in prepare answers first; it was a listing that dropped the three iOS
rows on macOS. It now asks `is_apple()`, a predicate the target table had
carried with NO READER AT ALL until this line.
`toolchain list`'s `graphCouldServe` CLAIMED THEM. Its own comment names
`aarch64-macos` as correctly absent on a Linux host -- and that row was absent
by ACCIDENT rather than by rule: its pin is empty, so `!info.pin.empty()`
excluded it. The iOS rows have a pin now (`llvm@22.1.8`, the ordinary payload),
so they entered the branch, found llvm in the index, and were listed on a host
that cannot produce them. The discriminator that comment appeals to is real and
is not the pin: it is whether a PACKAGE can supply the target's system, and no
package supplies an Apple SDK.
Asserted in both directions for all four Apple rows, because one direction is
what that test already calls an exclusion which must not become a tautology:
every Apple row is servable exactly where the SDK is.
AND A SKIP I WROTE FROM AN ASSUMPTION WAS REFUTED BY A ROW IN THE SAME TABLE.
The macOS scan also reported `graph x iOS` as `mismatch / build-failed`, and I
first wrote it off as out of the fixture's domain -- "an Apple row's system
comes from a located SDK and cannot be replaced by a graph-supplied musl".
`graph macos-arm64 aarch64-macos` is measured `ok / none` with `musl(graph)` in
its own column. The predicate I had written would have skipped that working
cell.
The real reason is one line of a dependency:
openkal-musl-0.3.5/port/src/okm_syscall.c:444: error: incompatible pointer
types passing 'uint64_t *' (aka 'unsigned long *') to parameter of type
'kal_u64 *' (aka 'unsigned long long *')
One width, two type identities. musl's own `<stdint.h>` spells `uint64_t` as
`unsigned long` on LP64; `kal_u64` is `__UINT64_TYPE__`, which clang defines as
`unsigned long long` for a DARWIN target. On every Linux and Windows musl
target the two coincide, which is why that package's CI has never seen it:
openkal-musl has never been built for an Apple target, and 0.13.1 has the same
shape. The skip is therefore scoped to the rows the diagnostic covers, its
comment says why macOS is NOT skipped, and the defect is recorded as a gap
belonging to openkal-musl -- the iOS rows do not depend on it, since their
system is the located SDK, which is the `payload` mode the tier rests on.
`mismatch` is not written into the table for any of this. The table's own
header forbids it, on the ground that writing one down declares a defect to be
the expectation.
Verified locally for this host after the change: 48 of 48 payload cells and 22
of 22 graph cells match the expected table.
Copy file name to clipboardExpand all lines: .agents/docs/2026-09-11-sdk-toolchains-and-ios-local-verification.md
+41Lines changed: 41 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -632,6 +632,46 @@ often. The claim now lives where the SDK is genuinely absent, which is every
632
632
non-Apple host, and it asserts four things about the message plus that the
633
633
refusal arrives before any payload is resolved.
634
634
635
+
### A predicate that was the same question until a second platform arrived
636
+
637
+
| finding | reading |
638
+
|---|---|
639
+
| the three iOS rows were absent from `toolchain list` on macOS, and present on linux-x86_64 | a target-matrix scan that reached three fewer cells than the table declares |
640
+
641
+
Two defects, one on each side of the same question, and the tier move is what
642
+
exposed them -- while the rows were `planned` the listing kept them
643
+
unconditionally, so neither could be seen.
644
+
645
+
`host_can_serve` asked `os == "macos"`, which was the same question as "is this
646
+
an Apple target" while macOS was the only one. An iOS target fell through to
647
+
the function's final `return false`, on every host including the one that
648
+
serves it. It now asks `is_apple()` -- a predicate the table had carried with
649
+
NO READER AT ALL until this line.
650
+
651
+
And `toolchain list`'s `graphCouldServe` claimed them. Its own comment names
652
+
`aarch64-macos` as correctly absent on a Linux host, and that row was absent by
653
+
ACCIDENT rather than by rule: its pin is empty, so `!info.pin.empty()`
654
+
excluded it. The iOS rows have a pin now, so they entered the branch, found
655
+
llvm in the index, and were listed on a host that cannot produce them. The
656
+
discriminator the comment appeals to is real and is not the pin -- it is
657
+
whether a PACKAGE can supply the target's system, and no package supplies an
658
+
Apple SDK.
659
+
660
+
### A skip I wrote from an assumption, refuted by a row in the same table
661
+
662
+
The macOS scan also reported `graph × iOS` as `mismatch / build-failed`, and I
663
+
first wrote it off as out of the fixture's domain -- "an Apple row's system
664
+
comes from a located SDK and cannot be replaced by a graph-supplied musl". A
665
+
row in the same table says otherwise: `graph macos-arm64 aarch64-macos` is
666
+
measured `ok / none`, with `musl(graph)` in its own c-abi column. The predicate
667
+
I had written would have skipped that working cell too.
668
+
669
+
The real reason is one line of a dependency and is in the gap table above: the
670
+
fixture's pinned `openkal-musl 0.3.5` does not compile for a Darwin target at
671
+
all. So the skip is scoped to the rows the diagnostic covers, and its comment
672
+
says why macOS is NOT skipped -- because the alternative was a rule that the
673
+
table next to it disproves.
674
+
635
675
### A fifth copy of a table that a checker covered four of
636
676
637
677
| finding | reading |
@@ -675,6 +715,7 @@ left rather than worked around.
675
715
| no whole-graph flag channel |`error: POSIX thread support was disabled in precompiled file '.../openkal.types.pcm' but is currently enabled`|`-pthread` is an ABI switch for every unit in the link including a dependency's; `openkal.task` is gated behind a feature so the absence is a link error rather than a present-and-failing operation |
676
716
|`xim:e2fsprogs`'s `debugfs`| SIGFPE on every filesystem-opening command, while dumpe2fs/e2fsck/tune2fs from the same build work | recorded in that recipe; nothing else in the index depends on it, and `android-system-image` now reads ext4 with `xim:7zip`|
677
717
| a device runner for `aarch64-ios`| none -- it needs a signature the developer owns | R12's subject, and a package cannot supply a signature |
718
+
|`openkal-musl` has never been built for an Apple target |`okm_syscall.c:444: error: incompatible pointer types passing 'uint64_t *' (aka 'unsigned long *') to parameter of type 'kal_u64 *' (aka 'unsigned long long *')`| one width, two type identities: musl's own `<stdint.h>` spells `uint64_t` as `unsigned long` on LP64, and `kal_u64` is `__UINT64_TYPE__`, which clang defines as `unsigned long long` for a DARWIN target. On every Linux and Windows musl target the two coincide, so that package's CI has never seen it. The current 0.13.1 has the same shape. It belongs to openkal-musl, and the iOS rows do not depend on it: their system is the located SDK, which is the `payload` mode the tier rests on |
0 commit comments