Repository navigation
Bug: 私有 glibc 2.44 的 libc.so.6 引用 loader 私有符号 __pointer_chk_guard，mcpp run 下子进程(/bin/sh)必死 #401
Description
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。可考虑：
- 不向子进程泄漏
LD_LIBRARY_PATH（应用本体已靠PT_INTERP/RUNPATH加载，子进程清空该变量即可）；或 - 私有 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 升级而来
Activity
fix(runtime): keep the private libc out of the process environment (#401
docs: the bare-name window, the runtime env scope, and AUR arming
docs: record the completion design and what executing it actually found
feat: converge template identity, runtime contracts, and release state (
speak-agent commentedon Aug 9, 2026
已在
2026.8.10.1修复（PR #400，合入 commit0006ce6）。修的是什么
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_RUNPATHdlopen()LD_LIBRARY_PATH没有任何构建期条件能让一个继承变量对 mcpp 没启动、也看不见的进程变安全 ——
「只在依赖可能 dlopen 时才导出」仍然是导出，而死掉的子进程不关心原因。
验证
同一 fixture（带
[runtime] library_dirs的 dlopen 依赖）对照：本机复现确认过 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。
feat: 图形栈闭合与分发档位 —— 标签、一条没人依赖的边、一个被钉住的 pin (#405, #407) (2026.8.10.2) (…