Bug: 私有 glibc 2.44 的 libc.so.6 引用 loader 私有符号 `__pointer_chk_guard`，mcpp run 下子进程(/bin/sh)必死

[FarnaHerry]

Bug: mcpp run 下被启动的应用 spawn 子进程（/bin/sh）必然失败 — 私有 glibc 2.44 的 libc.so.6 引用 loader 私有符号

现象

Linux 上 mcpp run 启动 GUI 应用后，应用每 spawn 一次子进程（popen / std::system，底层走 /bin/sh -c）就报：

sh: symbol lookup error: $HOME/.mcpp/registry/data/xpkgs/xim-x-glibc/2.44/lib64/libc.so.6: undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE

子进程启动即死，popen 拿到空输出。例如应用用 gsettings 探测系统深色主题，结果永远拿不到值。

最小复现（无需具体应用）

GL=$HOME/.mcpp/registry/data/xpkgs/xim-x-glibc/2.44
LD_LIBRARY_PATH="$GL/lib64" /bin/sh -c 'echo hi'

输出：

/bin/sh: symbol lookup error: $HOME/.mcpp/registry/data/xpkgs/xim-x-glibc/2.44/lib64/libc.so.6: undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE
exit=127

根因

• mcpp 私有 glibc 2.44 的 libc.so.6 里 __pointer_chk_guard 是未定义引用（objdump -T 显示 *UND* (GLIBC_PRIVATE)），该符号只由同版 ld-linux-x86-64.so.2 导出（g DO .data.rel.ro GLIBC_PRIVATE）。
• 系统二进制（如 /bin/sh）由系统 ld.so 加载（本例 Fedora glibc 2.43）。objdump -T /lib64/ld-linux-x86-64.so.2 确认系统 loader 不导出 __pointer_chk_guard。
• 于是当系统二进制通过继承的 LD_LIBRARY_PATH 加载到私有 2.44 libc 时，GLIBC_PRIVATE 符号解析失败 → 进程在启动阶段死掉。
• 私有 glibc 2.39 时代无此问题（libc.so.6 不引用该 loader 私有符号），是升到 2.44 后的回归。

影响面

mcpp run 会把 LD_LIBRARY_PATH 指到私有 glibc 目录并泄漏给子进程，所以任何在 mcpp 环境里启动、且会 spawn 子进程的应用都会命中：子进程失败、依赖子进程输出的逻辑静默降级。仅影响加载器无关的系统二进制；应用本体通过 PT_INTERP/RUNPATH 用私有 loader 加载，不受影响。

期望行为

mcpp run 不应导致子进程捡到私有 glibc。可考虑：

1. 不向子进程泄漏 LD_LIBRARY_PATH（应用本体已靠 PT_INTERP/RUNPATH 加载，子进程清空该变量即可）；或
2. 私有 glibc 自包含——libc.so.6 不引用需要同版 loader 才能满足的 GLIBC_PRIVATE 符号，使它在系统 loader 下也可加载。

环境

• 发行版：Fedora（内核 7.1.5-kairiki.finalv2.fc44.x86_64），系统 glibc 2.43
• mcpp：xlings 打包，私有 glibc 2.44（xim-x-glibc/2.44），mcpp.lock 重新解析后从 2.39 升级而来

[speak-agent]

已在 2026.8.10.1 修复（PR #400，合入 commit 0006ce6）。

修的是什么

mcpp run 曾把私有 glibc 目录放进 LD_LIBRARY_PATH。那个变量会被程序派生的每一个
进程继承，而 /bin/sh 由宿主 loader 加载（PT_INTERP 写死在可执行文件里，任何环境
变量都改不了），于是子进程在重定位阶段就死掉 —— 正是你报的那条。

关键是：这条环境项本来就没有收益。它存在的唯一理由是「可执行文件 DT_NEEDED 闭包
覆盖不到的 dlopen」，而产物的 RUNPATH 已经覆盖了这一点 —— link model 在
--dynamic-linker 旁就发了 -Wl,-rpath,<glibc>。实测：删掉这条环境项前后，
产物的 RUNPATH 逐字节相同。所以它只是在给每一个后代进程添麻烦。

决策收敛在新模块 src/platform/runtime_env_contract.cppm，写成作用域而不是条件判断：

	波及到
DT_RUNPATH	携带它的那一个对象，及其 dlopen()	逐二进制
LD_LIBRARY_PATH	本进程以及它派生的每一个进程	继承，一直传下去

没有任何构建期条件能让一个继承变量对 mcpp 没启动、也看不见的进程变安全 ——
「只在依赖可能 dlopen 时才导出」仍然是导出，而死掉的子进程不关心原因。

验证

同一 fixture（带 [runtime] library_dirs 的 dlopen 依赖）对照：

已发布 mcpp   LDLP=[…/runtime:…/xim-x-glibc/2.39/lib64]
2026.8.10.1   LDLP=[…/runtime]

本机复现确认过 2.44 payload 杀死 /bin/sh、2.39 不会 —— 这也是它能活这么久、
以及「我这儿是好的」毫无意义的原因。

回归锁：

• tests/e2e/208_private_libc_stays_in_the_binary.sh —— 目录在产物 RUNPATH 里、
  不在程序环境里、/bin/sh 子进程存活、dlopen 仍然解析得到，四条一起断言。
• tests/e2e/166_run_env_no_private_glibc.sh —— 原本断言相反（要求这条环境项必须在）。
  那条守卫的意图是对的（防止有人「修 LD_LIBRARY_PATH to fromsource glibc causes SIGSEGV in child process popen shell #291」时顺手把 dlopen 弄坏），但它锁的是机制
  而不是能力，而机制的前提是错的。现在它对两种形状都断言私有 libc 不进环境，
  能力断言交给 208。

隔离 fresh-home 冷启动验收里这两条都是 PASS。

顺带：本轮做图形栈验收时，把 <subos>/lib 放进 LD_LIBRARY_PATH 又原样复现了这条
崩溃（timeout 死于 __pointer_chk_guard），已作为证据记在
openxlings/xlings#525。
你报告里给的第 2 条方向（让私有 glibc 自包含）仍然是 xlings 侧值得做的事；
mcpp 这边采用的是第 1 条。