fix(toolchain): PayloadFirst artifacts had nowhere to find libgcc_s

The diagnostic added in the previous commit answered it on the first run:

  error while loading shared libraries: libgcc_s.so.1
  RUNPATH: <home>/data/xpkgs/xim-x-glibc/2.44/lib64      <- one entry
  ldd:     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1

The compiler's own runtime lives beside the compiler, not in the C library,
and a produced binary links it whether or not the build mentions it. gcc's
patched specs used to put that directory on the artifact; removing the specs
rewrite has to put it back, and only the Sysroot path did. One helper now
serves both modes.

Invisible where it was written: on any machine with a host toolchain the
artifact resolves libgcc_s.so.1 from /lib and runs. It failed only in a
throw-away home on CI.

The guard is a unit test, not an e2e. Which link mode an e2e reaches depends
on whether the machine happens to have a usable sysroot -- this one does, so a
PayloadFirst leg written for exactly this defect quietly ran Sysroot twice and
passed with the bug in place. Verified by removing the fix: the unit test goes
red, the e2e leg does not. The link model takes its mode from its input, so a
test can name the mode instead of hoping for it.

e2e 201 also now asserts that no artifact loads a library from /lib or
/usr/lib at all. "Does it run" was the wrong question -- it is answerable yes
on every developer machine while the artifact is quietly reaching outside the
sandbox.

  tests/unit/test_link_model_runtime_dirs.cpp  +4 (67 unit tests total)

Author: speak-agent

mcpp.toml

@@ -17,7 +17,7 @@ default-profile = "release"
 include_dirs = ["src/libs/json"]
 
 [toolchain]
-default = "gcc@16.1.0"
+default = "llvm@22.1.8"
 macos   = "llvm@22.1.8"
 windows = "llvm@20.1.7"
 

src/toolchain/linkmodel.cppm

@@ -320,11 +320,35 @@ ToolchainLinkModel resolve_link_model(const Toolchain& tc) {
     // cross-compile resolves by what it builds FOR.
     if (is_msvc_target(tc) || is_mingw_target(tc)) return lm;
 
+    // The compiler's OWN runtime lives beside it, not in the C library:
+    // libgcc_s.so.1 for GCC. A produced binary links it whether or not the
+    // build ever mentions it, so its directory has to be on the artifact's
+    // RUNPATH -- and gcc's patched specs used to put it there, which is
+    // exactly why removing that rewrite has to put it back.
+    //
+    // Both modes need this, and only one got it at first. PayloadFirst
+    // artifacts came out with a single RUNPATH entry (the glibc payload) and
+    // resolved libgcc_s.so.1 from the HOST -- or, on a machine without one,
+    // not at all: `error while loading shared libraries: libgcc_s.so.1`. This
+    // developer machine has a usable sysroot, so every local build took the
+    // other branch and the gap only surfaced on CI (e2e 29).
+    //
+    // Not for musl (self-contained sysroot, static world) and not for clang,
+    // which brings compiler-rt and libunwind instead.
+    auto add_compiler_runtime_dir = [&] {
+        if (is_musl_target(tc) || lm.clangDriver || tc.binaryPath.empty()) return;
+        std::error_code lec;
+        auto gccLib = tc.binaryPath.parent_path().parent_path() / "lib64";
+        if (std::filesystem::exists(gccLib, lec))
+            lm.libDirs.push_back(gccLib);
+    };
+
     auto payload_first = [&] {
         auto& pp = *tc.payloadPaths;
         lm.mode   = CLibMode::PayloadFirst;
         lm.crtDir = pp.glibcLib;
         lm.libDirs.push_back(pp.glibcLib);
+        add_compiler_runtime_dir();
         lm.systemIncludes.push_back(pp.glibcInclude);
         if (!pp.linuxInclude.empty())
             lm.systemIncludes.push_back(pp.linuxInclude);
@@ -358,12 +382,7 @@ ToolchainLinkModel resolve_link_model(const Toolchain& tc) {
             lm.loader = resolve_loader(tc.payloadPaths->glibcLib, tc.targetTriple);
             lm.libDirs.push_back(tc.payloadPaths->glibcLib);
         }
-        if (!is_musl_target(tc) && !tc.binaryPath.empty()) {
-            std::error_code lec;
-            auto gccLib = tc.binaryPath.parent_path().parent_path() / "lib64";
-            if (std::filesystem::exists(gccLib, lec))
-                lm.libDirs.push_back(gccLib);
-        }
+        add_compiler_runtime_dir();
         // Supplement kernel headers when the sysroot lacks them (glibc's
         // local_lim.h needs <linux/limits.h>). Self-contained musl sysroots
         // ship their own; a cross target must not see host-arch headers.

tests/e2e/201_gcc_no_specs_pollution.sh

@@ -20,6 +20,7 @@
 # never something a build asked for.
 set -euo pipefail
 
+SELF_DIR=$(cd "$(dirname "$0")" && pwd)   # captured before any cd
 TMP=$(mktemp -d)
 trap 'rm -rf "$TMP"' EXIT
 export MCPP_HOME=$HOME/.mcpp
@@ -80,4 +81,84 @@ echo "$file_out" | grep -q 'interpreter .*xim-x-glibc' || {
 out=$("$bin" 2>&1) || { echo "binary did not run: $out"; exit 1; }
 echo "$out" | grep -q 'Hello' || { echo "unexpected output: $out"; exit 1; }
 
-echo "PASS: gcc artifact carries only the RUNPATH this build asked for"
+# 4. Nothing loads from the host.
+#
+# "Does it run" is not this question, and answering the wrong one is how a
+# real gap survived: with the compiler's own lib dir missing from RUNPATH,
+# artifacts resolved libgcc_s.so.1 from /lib and ran perfectly on any machine
+# that has a host toolchain -- which is every developer machine. It failed
+# only on CI's throw-away home, and only as `error while loading shared
+# libraries`, with no indication of what had gone missing or why.
+#
+# Asking where each library actually came from makes the same defect visible
+# everywhere, host toolchain or not.
+if command -v ldd > /dev/null 2>&1; then
+    host_libs=$(ldd "$bin" 2>/dev/null \
+                | grep -E '=> +(/lib|/usr/lib|/lib64|/usr/lib64)/' || true)
+    if [[ -n "$host_libs" ]]; then
+        echo "the artifact loads libraries from the host:"
+        echo "$host_libs" | sed 's/^/  /'
+        echo "Every shared library a payload build needs is in the payload;"
+        echo "reaching outside it means a directory is missing from RUNPATH."
+        exit 1
+    fi
+fi
+
+# ── The same assertions again, in the OTHER link mode ────────────────────
+#
+# RUNPATH is built by two separate paths -- CLibMode::Sysroot and
+# CLibMode::PayloadFirst -- and a machine only ever takes one of them. This
+# one has a usable sysroot, so everything above ran through Sysroot mode and
+# PayloadFirst went untested here for as long as this file has existed.
+#
+# It was not academic: PayloadFirst omitted the compiler's own lib dir, so
+# artifacts resolved libgcc_s.so.1 from the host. Invisible on any machine
+# with a host toolchain; on CI's throw-away home it was `error while loading
+# shared libraries` with no further explanation.
+#
+# A home with payloads but no subos usually has no sysroot to find, which is
+# what selects PayloadFirst -- but "usually" is the honest word: where gcc
+# reports a baked sysroot that happens to exist (another checkout on the same
+# machine), mcpp accepts it as a last resort and this leg runs Sysroot mode a
+# second time instead. Which is what it does on the machine these words were
+# written on.
+#
+# So the deterministic guard for this invariant is the unit test
+# (tests/unit/test_link_model_runtime_dirs.cpp), which names the mode rather
+# than arranging for it. This leg is still worth running: it covers a second
+# home shape end to end, and on CI -- where the baked path does not exist --
+# it is the real thing.
+export MCPP_HOME="$TMP/payload-first-home"
+MCPP_INHERIT_CONFIG=0 MCPP_INHERIT_SUBOS=0 \
+    source "$SELF_DIR/_inherit_toolchain.sh"
+
+cd "$TMP"
+"$MCPP" new pf > /dev/null
+cd pf
+cat >> mcpp.toml <<'EOF'
+
+[toolchain]
+linux = "gcc@16.1.0"
+EOF
+
+"$MCPP" build > "$TMP/pf.log" 2>&1 || {
+    cat "$TMP/pf.log"; echo "payload-first build failed"; exit 1; }
+
+pfbin=$(find target -type f -name pf -path '*/bin/*' | head -1)
+[[ -n "$pfbin" ]] || { echo "no payload-first binary produced"; exit 1; }
+
+pf_host=$(ldd "$pfbin" 2>/dev/null \
+          | grep -E '=> +(/lib|/usr/lib|/lib64|/usr/lib64)/' || true)
+if [[ -n "$pf_host" ]]; then
+    echo "the payload-first artifact loads libraries from the host:"
+    echo "$pf_host" | sed 's/^/  /'
+    echo "RUNPATH was:"
+    "$readelf" -d "$pfbin" 2>/dev/null | grep -iE 'RUNPATH|RPATH' | sed 's/^/  /'
+    exit 1
+fi
+
+"$pfbin" > /dev/null 2>&1 || {
+    echo "payload-first binary did not run: $("$pfbin" 2>&1 | head -2)"; exit 1; }
+
+echo "PASS: gcc artifacts carry only the RUNPATH the build asked for and load"
+echo "      nothing from the host — in both sysroot and payload-first modes"

tests/unit/test_link_model_runtime_dirs.cpp

@@ -0,0 +1,122 @@
+// An artifact must find every library it needs inside the sandbox — in BOTH
+// link modes.
+//
+// RUNPATH is assembled by two separate paths, CLibMode::Sysroot and
+// CLibMode::PayloadFirst, and any given machine only ever takes one of them.
+// The compiler's own runtime (libgcc_s.so.1) lives beside the compiler, not in
+// the C library, and a produced binary links it whether or not the build ever
+// mentions it. gcc's patched specs used to supply that directory; removing the
+// specs rewrite therefore has to supply it explicitly — and at first only the
+// Sysroot path did.
+//
+// The consequence was invisible where it was written: on a machine with a host
+// toolchain the artifact simply resolved libgcc_s.so.1 from /lib and ran. It
+// failed only in a throw-away home on CI, as `error while loading shared
+// libraries` with nothing said about what was missing.
+//
+// Asserted here rather than in e2e on purpose. Which mode an e2e reaches
+// depends on whether the machine happens to have a usable sysroot — this one
+// does, so an e2e leg written for PayloadFirst quietly ran Sysroot twice and
+// passed with the defect in place. The link model takes its mode from its
+// input, so a test can name the mode instead of hoping for it.
+
+#include <gtest/gtest.h>
+
+import std;
+import mcpp.toolchain.linkmodel;
+import mcpp.toolchain.model;
+
+namespace tc = mcpp::toolchain;
+
+namespace {
+
+void touch(const std::filesystem::path& p) {
+    std::filesystem::create_directories(p.parent_path());
+    std::ofstream(p) << "x";
+}
+
+// A payload tree with a glibc beside a gcc, as xlings lays them out.
+struct Payload {
+    std::filesystem::path root, compiler, glibcLib, gccLib, sysroot;
+    Payload() {
+        root = std::filesystem::temp_directory_path()
+             / std::format("mcpp_linkmodel_{}", std::random_device{}());
+        auto xpkgs = root / "data" / "xpkgs";
+        compiler = xpkgs / "xim-x-gcc" / "16.1.0" / "bin" / "g++";
+        touch(compiler);
+        gccLib = xpkgs / "xim-x-gcc" / "16.1.0" / "lib64";
+        touch(gccLib / "libgcc_s.so.1");
+        glibcLib = xpkgs / "xim-x-glibc" / "2.39" / "lib64";
+        touch(glibcLib / "libc.so.6");
+        touch(glibcLib / "ld-linux-x86-64.so.2");
+        touch(xpkgs / "xim-x-glibc" / "2.39" / "include" / "features.h");
+        sysroot = root / "subos" / "default";
+        touch(sysroot / "usr" / "include" / "stdlib.h");
+    }
+    ~Payload() { std::error_code ec; std::filesystem::remove_all(root, ec); }
+
+    tc::Toolchain toolchain(bool withSysroot) const {
+        tc::Toolchain t;
+        t.compiler     = tc::CompilerId::GCC;
+        t.version      = "16.1.0";
+        t.binaryPath   = compiler;
+        t.targetTriple = "x86_64-linux-gnu";
+        t.runtimeBinding = "glibc@2.39";
+        tc::PayloadPaths pp;
+        pp.glibcLib     = glibcLib;
+        pp.glibcInclude = glibcLib.parent_path() / "include";
+        t.payloadPaths  = pp;
+        if (withSysroot) t.sysroot = sysroot;
+        return t;
+    }
+};
+
+std::string joined(const tc::ToolchainLinkModel& lm) {
+    auto id = [](const std::filesystem::path& p) { return p.string(); };
+    std::string s;
+    for (auto& tok : lm.link_tokens(id)) { s += tok; s += ' '; }
+    return s;
+}
+
+TEST(LinkModelRuntimeDirs, PayloadFirstCarriesTheCompilerRuntime) {
+    Payload p;
+    auto lm = tc::resolve_link_model(p.toolchain(/*withSysroot=*/false));
+    ASSERT_EQ(lm.mode, tc::CLibMode::PayloadFirst);
+    auto line = joined(lm);
+    EXPECT_NE(line.find("-Wl,-rpath," + p.gccLib.string()), std::string::npos)
+        << "libgcc_s.so.1 lives here and nothing else will find it:\n" << line;
+}
+
+TEST(LinkModelRuntimeDirs, SysrootCarriesTheCompilerRuntime) {
+    Payload p;
+    auto lm = tc::resolve_link_model(p.toolchain(/*withSysroot=*/true));
+    ASSERT_EQ(lm.mode, tc::CLibMode::Sysroot);
+    auto line = joined(lm);
+    EXPECT_NE(line.find("-Wl,-rpath," + p.gccLib.string()), std::string::npos)
+        << line;
+}
+
+// The C library's own directory, in both modes, for the same reason.
+TEST(LinkModelRuntimeDirs, BothModesCarryTheCLibrary) {
+    Payload p;
+    for (bool withSysroot : {false, true}) {
+        auto line = joined(tc::resolve_link_model(p.toolchain(withSysroot)));
+        EXPECT_NE(line.find("-Wl,-rpath," + p.glibcLib.string()),
+                  std::string::npos)
+            << "withSysroot=" << withSysroot << "\n" << line;
+    }
+}
+
+// And the interpreter. A sysroot says where headers live; it says nothing
+// about which loader runs the result, and gcc's `*link:` no longer answers.
+TEST(LinkModelRuntimeDirs, BothModesNameTheInterpreter) {
+    Payload p;
+    for (bool withSysroot : {false, true}) {
+        auto line = joined(tc::resolve_link_model(p.toolchain(withSysroot)));
+        EXPECT_NE(line.find("--dynamic-linker=" + p.glibcLib.string()),
+                  std::string::npos)
+            << "withSysroot=" << withSysroot << "\n" << line;
+    }
+}
+
+}  // namespace