fix(build): the managed tools run on their own RPATH; the library path is given only to a compiler without one

Author: Sunrisepeak

.agents/docs/2026-10-10-one-source-one-meaning-design.md

@@ -31,6 +31,10 @@ status: landed
 - D28：以 argv 启动的 shell 由 `posix_shell()` 解析；`popen` 与 `std::system` 仍用 C 库的 `/bin/sh`，
   因此 Android 的基线是 10 及以上。
 - D23：mcpp 把 xlings 的 `extract`、`hook` 事件显示为 `Installing …` 行，并写入日志；不另加 30 s 心跳。
+- D29：受管载荷的程序带有 xlings 安装时写入的 RPATH，不依赖 `LD_LIBRARY_PATH`（实测 clang、clang-scan-deps、
+  llvm-ar、lld 去掉该变量都能运行）。因此在 Linux 上该变量不再进入 ninja 的环境，也不加在工具上；只有编译器
+  本身没有 RPATH/RUNPATH 时（以路径指定的工具链），才以 `env LD_LIBRARY_PATH=… <tool>` 前缀加在工具上。
+  这样 `build.ninja` 中 `cxx =` 的写法对受管工具链不变（tests/e2e/188 读取它）。
 - D26 以 `degraded`（`build-program/provides`）实现。
 - 工作空间层的解析：`[workspace.*]` 下的文档由同一个 `parse_document` 读取，保留原值的行号。
 - 测试：e2e 893–901（在 2026.10.8.1 上全部失败）；Windows 探测由单元测试覆盖；D27 的两个 job 在

CHANGELOG.md

@@ -44,9 +44,10 @@
 - Write nothing at an action's outputs before the action runs. A generated
   translation unit enters the plan from its action's declaration; a generated
   module interface without `.provides(...)` is reported as degraded.
-- Pass the managed toolchain's library path on Linux to the tools that need
-  it (`$cxx`, `$cc`, `$ar`, `clang-scan-deps`) instead of ninja's environment,
-  so no shell ninja starts loads the toolchain's libc++.
+- Keep the managed toolchain's library path out of ninja's environment on
+  Linux, so no shell ninja starts loads the toolchain's libc++. The managed
+  tools find their libraries through their own RPATH; a compiler without one
+  gets the path on the tools alone.
 - Pin xlings 2026.10.10.2 and bootstrap from mcpp 2026.10.8.1.
 
 ### Added

src/build/ninja_backend.cppm

@@ -1453,8 +1453,7 @@ std::string emit_ninja_string(const BuildPlan& plan, std::string* placements,
         plan.toolchain.binaryPath, plan.toolchain.targetTriple);
 
     if (!fsObjcopy.empty()) {
-        append("objcopy = " + mcpp::platform::linux_::build_clean_ld_library_path_prefix(
-                   plan.toolchain.compilerRuntimeDirs) + escape_ninja_path(fsObjcopy) + "\n\n");
+        append("objcopy = " + escape_ninja_path(fsObjcopy) + "\n\n");
         // ── The raw image a flasher takes ──────────────────────────────────
         //
         // A SEPARATE EDGE with the ELF as its input, not a second output of
@@ -1484,20 +1483,26 @@ std::string emit_ninja_string(const BuildPlan& plan, std::string* placements,
     const std::string launch = flags.launcher.empty() ? std::string{}
         : escape_ninja_path(std::filesystem::path(flags.launcher)) + " ";
     // D29: THE TOOLCHAIN'S PRIVATE LIBRARIES ARE THE TOOLCHAIN'S. A managed
-    // LLVM's `clang`, `llvm-ar` and `clang-scan-deps` find their own libc++ and
-    // libLLVM through LD_LIBRARY_PATH, and that path used to be in ninja's
-    // environment -- so every `/bin/sh -c` ninja starts had it too. A shell
-    // that links libc++ (Android's bionic `sh`) then loaded the LLVM's,
+    // LLVM's library directories used to be put in ninja's environment as
+    // LD_LIBRARY_PATH, so every `/bin/sh -c` ninja starts inherited them. A
+    // shell that links libc++ (Android's bionic `sh`) then loaded the LLVM's,
     // built for glibc, and died before running anything:
     //   CANNOT LINK EXECUTABLE "/bin/sh": .../xim-x-llvm/23.1.3/lib/
     //     aarch64-unknown-linux-gnu/libc++.so is too small
-    // (termux-docker, design 2026-10-10 §13). The path now prefixes the tools
-    // that need it and reaches nothing else; macOS keeps no such path at all
+    // (termux-docker, design 2026-10-10 §13). A managed payload's programs
+    // carry their own search path (the RPATH xlings writes at install), so on
+    // Linux the variable reaches no process ninja starts. A compiler without
+    // one -- a toolchain named by path -- gets it on the tools alone, as an
+    // `env` prefix. macOS keeps no such path at all
     // (`runtime_library_path_key`), Windows keeps its PATH.
-    const std::string toolEnv = mcpp::platform::is_linux
-        ? mcpp::platform::linux_::build_clean_ld_library_path_prefix(
-              plan.toolchain.compilerRuntimeDirs)
-        : std::string{};
+    const std::string toolEnv = [&]() -> std::string {
+        if (!mcpp::platform::is_linux || plan.toolchain.compilerRuntimeDirs.empty()) return {};
+        if (auto facts = mcpp::platform::elf::inspect_elf_runtime(flags.cxxBinary);
+            facts && facts->searchPathTag != mcpp::platform::elf::SearchPathTag::None)
+            return {};
+        return mcpp::platform::linux_::build_clean_ld_library_path_prefix(
+            plan.toolchain.compilerRuntimeDirs);
+    }();
     append(std::format("cxx       = {}{}{}\n", toolEnv, launch, escape_ninja_path(flags.cxxBinary)));
     // The driver alone, for the dependency scan: `clang-scan-deps` reads its
     // argv[0] as the compiler (and the resource directory beside it), and a