Repository navigation
openkal cross-build macos leg: x86_64-linux-gnu refused although openkal-linux@0.16.1 is in the graph (graph-supply release not firing) #782
Description
Activity
根因修正(代码级走查后,推翻本 issue 初稿的「释放条件未生效」表述——释放根本没机会运行):
真正的 firing site 是工具链解析处的过度守卫,不是 target_side 的释放条件:
- 早期门(
toolchain.cpp:745)在 mac 宿主上对x86_64-linux-gnu置unservedTargetDiagnosis(携带,不失败)。 - 工具链解析(
toolchain.cpp:1305-1322)有个守卫:诊断已置时autoInstall=false(为 ubuntu-arm 装 x86_64-only 交叉包硬失败的场景而加,注释称 "attempting cannot help either of them" / "Skipping leaves BOTH later paths intact")。 resolve_xpkg_path(llvm@22.1.8, autoInstall=false)在载荷未装时返回空 → 立即返回携带的诊断,step9 的 graph 供应释放(target_side.cpp:971,system_from_graph())永远没机会运行。注释里 "leaves BOTH later paths intact" 不成立:后面的释放路径恰恰需要这个载荷解析成功。
为什么以前能过:same-source 示例钉
llvm@22.1.8;当时 openkal-cross job 显式安装 22.1.8(mcpp 自举同为 22.1.8)→ 载荷已在机器上 → 解析成功 → 释放生效。本 PR 把线移到 23.1.3 后,job 装 23.1.3、22.1.8 不再在机器上 → 守卫引爆。修复方向:守卫不应跳过安装——诊断已置时应照常尝试安装(载荷只是 retargetable clang,graph 供应系统侧时它正是需要的),安装失败且诊断已置时才返回诊断;这样 "attempting cannot help" 的原场景(装不上硬失败,被诊断替换)与 graph 供应场景都被诚实覆盖。示例钉 22.1.8→23.1.3 是可选的即时解(job 已装 23.1.3),但不修引擎缺陷。
- 早期门(
- added 3 commits that reference this issue
on Oct 7, 2026 Fixed in #781 and verified by CI: the openkal macos leg (the exact failing arrangement — a retargetable clang declared for a linux-gnu guest the host payload cannot serve, with
openkal-linuxsupplying the system from the graph) is green in run 37666251572 along with the linux and windows legs.The repair: a held unserved-target diagnosis no longer skips the toolchain install for a USER-DECLARED toolchain (
[toolchain],--toolchain,MCPP_TOOLCHAIN) — the declaration outranks the payload matrix, the same standing the[target.X] toolchainescape hatch has. An ENGINE-CHOSEN toolchain (row pin, host default) still skips when the target is unservable, releasing the held diagnosis — that half is what keeps a foreign-arch payload from being extracted on a wrong-arch host (measured on linux-aarch64, where the restored cache held an x86_64-only gcc).
现象
PR #781 的 CI 是 openkal-cross 工作流自 2026-10-01(feat/build-sources)以来第一次真正运行(main 侧 openkal job 被路径门控跳过,见 run 37401792942)。macos 腿在第一个目标即失败:
而依赖图刚刚下载了
mcpplibs:openkal-linux@0.16.1(openkal 的 linux 系统侧供应包)。归属
[toolchain] default = "llvm@22.1.8",示例构建用 22.1.8;拒绝路径(src/build/prepare/toolchain.cpp的 unserved-target 诊断与src/toolchain/registry.cppm的host_can_serve)本 PR 未触碰。方向
graph-supply 的释放条件(
unservedTargetDiagnosis在图解析后何处被清除、openkal-linux 声明的供应在 macos 宿主上为何不计入)需要一次走查;可能涉及 2026.10.2 以来 prepare/scan 或 target-side 的改动。证据:run 37616774345,job 112780571354(macos leg,12:03:41 处失败);诊断全文见日志。