xim: archs 不含当前架构时应直接拒绝,而不是下载到 404

[Sunrisepeak]

现象

ci-aarch64-fresh-install 的 self-host 步在 aarch64 runner 上失败:

[error] download failed for xim:binutils@2.42: HTTP 404
[error] download failed for xim:gcc@16.1.0: HTTP 404
error: host toolchain for build.mcpp ('gcc@16.1.0'): xlings install of 'xim:gcc@16.1.0' failed

该 job 自 2026-08-03 起在 main 上一直红。此前它更早地死在自举 pin 上
(xlings: version '2026.8.5.3' not found for 'mcpp',已在 #366 修掉),
所以这一层是被那次修复暴露出来的,不是新引入的。

根因

xim-pkgindex 的 pkgs/g/gcc.lua 声明 archs = { "x86_64" } —— gcc 这个包
本来就没有 aarch64 载荷,404 是必然的。

而 mcpp 在 aarch64 上仍然请求它,是因为 host 工具链只按 OS 选择:

[toolchain]
default = "gcc@16.1.0"     # ← 在 aarch64 上同样命中

[target.aarch64-linux-musl] 只决定 target 工具链(而且是 host-aware 的,
所以那一半是对的);build.mcpp 的 host 编译走 [toolchain],那张表的键是
default / macos / windows,没有 arch 这根轴。

两个可分别处理的缺口

1. 索引侧:xim 应当在 archs 不含当前 arch 时给出「本平台无此包」的
   诊断,而不是照常发起下载再 404。现在的报错要读三层才能知道原因。
2. mcpp 侧:host 工具链的选择缺 arch 轴。一个包在 x86_64 上可用、在
   aarch64 上不存在,是常态而不是异常;[toolchain] 需要能表达它,否则
   aarch64 用户唯一的出路是改 manifest。

第 2 条是设计问题,不是一行修复:[toolchain] 的键空间目前是 OS,加 arch
要么走 cfg(...) 谓词(与 [target.'cfg(...)'] 同一套文法,一致但更重),
要么承认 host 工具链本身就该由 triple 索引。先记下来。

影响

不影响任何 x86_64 / macOS / Windows 路径,也不影响 aarch64 上已发布二进制
的使用 —— 只影响在 aarch64 上从源码自举。

[Sunrisepeak]

归因更正 —— 这个 issue 的前提是错的,已在 #366 用另一种方式修掉。

我原先写的是「mcpp 侧 host 工具链的选择缺 arch 轴」,并据此提议给 [toolchain] 加选择器语法。那是错的。

xlings 生态早就支持 aarch64:xlings-res 的 musl-gcc 发行版里就有

musl-gcc-16.1.0-linux-aarch64.tar.gz     104.2MB
musl-gcc-16.1.0-linux-x86_64.tar.gz      109.7MB

而 xim-pkgindex 的 pkgs/g/gcc.lua 声明 archs = { "x86_64" }。所以缺的不是「让用户去写 arch」,而是 mcpp 问错了包。

同一次构建里 target 一侧是对的:

Resolved gcc@16.1.0 → aarch64-linux-musl → xim-x-musl-gcc/16.1.0/bin/aarch64-linux-musl-g++

因为 target 一侧把 triple 注入了 spec,to_xim_package 的 musl 分支按「同一 target,两种载荷形态」选中了原生包。而 build.mcpp 的 host 解析刻意不注入 target(// Deliberately NO target injection),于是落到最后那条 glibc 分支,拿到只有 x86_64 资产的 gcc。

「这个 spec 在这台机器上对应哪个载荷」正是 to_xim_package 存在的意义,它上面那条 musl 分支已经在回答同一个问题的另一半。修复因此落在那里:Linux 上瞄准本机的 GCC spec,在非 x86_64 架构上解析到 musl-gcc。用户不该被要求去编码「某个工具链包是为哪些架构构建的」。

判定抽成接收 host arch 的自由函数(而不是读编译期常量),这样 aarch64 的答案能在 x86_64 机器上被单测覆盖 —— 测一个手边没有的架构,正是需要的。

留在这个 issue 里的,只剩索引侧那一条:xim 在 archs 不含当前架构时应当直接说「本平台无此包」,而不是照常发起下载再 404 —— 现在的报错要读三层才能到原因。这条与 mcpp 无关,标题与正文我已按此收窄。