fix(toolchain): aarch64 上原生 GCC 的载荷是 musl-gcc,不是 glibc gcc (#367)

`ci-aarch64-fresh-install` 报 `download failed for xim:gcc@16.1.0: HTTP 404`。

**先前的归因是错的**:我判成「`[toolchain]` 缺 arch 轴」,并动手给 manifest 加了
一根选择器轴。生态其实**早就支持 aarch64** —— xlings-res 的 musl-gcc 发行版里
就有 `musl-gcc-16.1.0-linux-aarch64.tar.gz`,而 `xim:gcc` 声明的是
`archs = { "x86_64" }`。所以缺的不是让用户去写 arch,而是 mcpp 问错了包。

同一台机器上 target 一侧是对的:
`gcc@16.1.0 → aarch64-linux-musl → xim-x-musl-gcc`。因为 target 一侧把 triple
注入了 spec,`to_xim_package` 的 musl 分支便按「同一 target,两种载荷形态」选中
了原生包。而 build.mcpp 的 **host** 解析刻意不注入 target,于是落到最后那条
glibc 分支,拿到只有 x86_64 资产的 `gcc`。

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

同时撤回上一版那个「host 工具链装不上就回退到 target 工具链」的兜底 —— 它是
错误归因的产物;正确解析之后它是死代码,而一条失败路径上的隐式回退不该白留。

判定抽成自由函数并接收 host arch,而不是读编译期常量:这样 aarch64 的答案能在
x86_64 机器上被测到 —— 而「测一个手边没有的架构」正是重点。

Author: speak-agent

src/build/prepare.cppm

@@ -1812,34 +1812,6 @@ prepare_build(bool print_fingerprint,
         mcpp::fetcher::InstallProgressHandler progress;
         auto payload = fetcher.resolve_xpkg_path(pkg.target(), /*autoInstall=*/true, &progress);
         if (!payload) {
-            // The pinned host toolchain is not obtainable here. Before giving
-            // up, ask whether we already HAVE a compiler that runs on this
-            // machine: when the resolved target differs from the host only in
-            // its libc environment (aarch64-linux-musl on an aarch64 Linux
-            // host), the target toolchain is native — it runs here and the
-            // binaries it produces run here — so it is a perfectly good
-            // compiler for a build program.
-            //
-            // Without this, a whole architecture is a dead end for any project
-            // whose graph contains a build.mcpp: `[toolchain]` is keyed by OS
-            // with no arch axis (#367), so `default = "gcc@16.1.0"` is what
-            // aarch64 asks for too, and that package declares
-            // `archs = { "x86_64" }` — the download 404s and the build stops.
-            // A toolchain that is already on disk and already correct should
-            // not be unusable because a second, redundant one is missing.
-            auto hostT = mcpp::toolchain::triple::host_triple();
-            auto tgtT  = mcpp::toolchain::triple::parse(overrides.target_triple);
-            if (tgtT && tgtT->arch == hostT.arch && tgtT->os == hostT.os) {
-                mcpp::diag::warning("toolchain/host-fallback", std::format(
-                    "the pinned host toolchain '{}' could not be provisioned "
-                    "({}), so build.mcpp will be compiled with the target "
-                    "toolchain instead — it is native here ({} vs host {}). "
-                    "Pin a host toolchain that exists on this architecture to "
-                    "silence this.",
-                    *tcSpec, payload.error().message, tgtT->str(), hostT.str()));
-                hostTcCache = std::pair{explicit_compiler, *tc};
-                return *hostTcCache;
-            }
             return std::unexpected(std::format(
                 "host toolchain for build.mcpp ('{}'): {}", *tcSpec,
                 payload.error().message));

src/toolchain/registry.cppm

@@ -86,6 +86,20 @@ void print_compat_hint(const ToolchainSpec& spec);
 // The (family, target, host) → xim package mapping — the distribution layer.
 XimToolchainPackage to_xim_package(const ToolchainSpec& spec);
 
+// #367: does a GCC spec aimed at the NATIVE Linux host resolve to the
+// `musl-gcc` payload rather than the glibc `gcc` one?
+//
+// `xim:gcc` publishes x86_64 assets only (`archs = { "x86_64" }`); the GCC the
+// ecosystem ships for other Linux architectures is `musl-gcc`, which does
+// publish them (aarch64 included, verified against xlings-res). Asking for
+// `gcc` on aarch64 404s.
+//
+// A free function taking the host arch rather than reading the compile-time
+// constant, so the aarch64 answer is testable on an x86_64 machine — the whole
+// point being an architecture the developer is not sitting in front of.
+bool gcc_native_payload_is_musl(std::string_view hostArch, bool isLinux,
+                                const triple::Triple& target);
+
 ToolchainSpec with_resolved_xim_version(const ToolchainSpec& spec,
                                         std::string_view ximVersion);
 
@@ -209,6 +223,16 @@ void print_compat_hint(const ToolchainSpec& spec) {
     compat::print_hint_once(spec.compatHint);
 }
 
+bool gcc_native_payload_is_musl(std::string_view hostArch, bool isLinux,
+                                const triple::Triple& target) {
+    if (!isLinux) return false;
+    if (hostArch == "x86_64") return false;      // the glibc payload exists here
+    // "Native" = no explicit target, or one naming this same machine. A CROSS
+    // target keeps its own payload rule (the `<triple>-gcc` packages above).
+    return target.empty()
+        || (target.os == "linux" && target.arch == hostArch);
+}
+
 XimToolchainPackage to_xim_package(const ToolchainSpec& spec) {
     XimToolchainPackage pkg;
     pkg.displaySpec = spec.display();
@@ -271,7 +295,30 @@ XimToolchainPackage to_xim_package(const ToolchainSpec& spec) {
         return pkg;
     }
 
-    // Host target (or linux-gnu): the glibc gcc package.
+    // Host target (or linux-gnu): the glibc gcc package — on x86_64.
+    //
+    // #367: `xim:gcc` declares `archs = { "x86_64" }` and publishes assets for
+    // that arch only. The GCC the ecosystem ships for other Linux
+    // architectures is `musl-gcc`, which does publish them (aarch64 included).
+    // Asking for `gcc` on aarch64 therefore 404s — and because a `build.mcpp`
+    // host compile resolves the toolchain spec with NO target injection, it
+    // landed here and made every project whose graph contains a build program
+    // unbuildable on aarch64, with `--target aarch64-linux-musl` fixing only
+    // the target half.
+    //
+    // "Which payload backs this spec on this machine" is exactly the question
+    // this function exists to answer — the musl branch above already answers
+    // its half the same way ("same target, two payload shapes"). The knowledge
+    // belongs here rather than in every manifest: a user should not have to
+    // encode which architectures a toolchain package was built for.
+    if (gcc_native_payload_is_musl(mcpp::platform::host_arch,
+                                   mcpp::platform::is_linux, t)) {
+        const auto mt = host_musl_triple();
+        pkg.ximName = "musl-gcc";
+        pkg.frontendCandidates = { mt.str() + "-g++", "g++" };
+        return pkg;   // no glibc specs fixup: that payload is not glibc-linked
+    }
+
     pkg.ximName = "gcc";
     pkg.frontendCandidates = {"g++"};
     pkg.needsGccPostInstallFixup = true;

tests/unit/test_toolchain_registry.cpp

@@ -3,6 +3,7 @@
 import std;
 import mcpp.platform;
 import mcpp.toolchain.registry;
+import mcpp.toolchain.triple;
 
 using namespace mcpp::toolchain;
 
@@ -187,3 +188,39 @@ TEST(ToolchainRegistry, IdentifiesToolchainPayloadsAndSkipsOthers) {
     EXPECT_FALSE(identify_xim_payload("python").has_value());
     EXPECT_FALSE(identify_xim_payload("linux-headers").has_value());
 }
+
+// #367: which GCC payload backs a NATIVE Linux build.
+//
+// `xim:gcc` declares `archs = { "x86_64" }` and publishes assets for that arch
+// only; the GCC the ecosystem ships for other Linux architectures is
+// `musl-gcc` (xlings-res carries musl-gcc-16.1.0-linux-aarch64.tar.gz). Asking
+// for `gcc` on aarch64 therefore 404s — which is what made every project whose
+// graph contains a `build.mcpp` unbuildable there, since a build program's
+// host compile resolves the spec with no target injection and landed on the
+// glibc package.
+//
+// Tested through a free function taking the host arch rather than the
+// compile-time constant, precisely so the aarch64 answer is checkable from an
+// x86_64 machine.
+TEST(ToolchainRegistry, NativeGccPayloadFollowsWhatTheArchActuallyPublishes) {
+    using mcpp::toolchain::gcc_native_payload_is_musl;
+    const mcpp::toolchain::triple::Triple none{};
+
+    // x86_64: unchanged — the glibc package is the one that exists.
+    EXPECT_FALSE(gcc_native_payload_is_musl("x86_64", true, none));
+    EXPECT_FALSE(gcc_native_payload_is_musl(
+        "x86_64", true, {"x86_64", "linux", "gnu"}));
+
+    // aarch64: the glibc package has no asset, musl-gcc does.
+    EXPECT_TRUE(gcc_native_payload_is_musl("aarch64", true, none));
+    EXPECT_TRUE(gcc_native_payload_is_musl(
+        "aarch64", true, {"aarch64", "linux", "gnu"}));
+
+    // A CROSS target keeps its own payload rule — this is about the native
+    // one, and `<triple>-gcc` packages answer for the rest.
+    EXPECT_FALSE(gcc_native_payload_is_musl(
+        "aarch64", true, {"x86_64", "linux", "gnu"}));
+
+    // Non-Linux hosts are out of scope: macOS uses llvm, Windows mingw/msvc.
+    EXPECT_FALSE(gcc_native_payload_is_musl("aarch64", false, none));
+}