Repository navigation
[Linux] mcpp run 无法启动：私有 glibc 2.39 与系统库 GLIBC 版本冲突，以及切换 glibc 2.44 过程中的排查与发现 #392
Description
Activity
- added 7 commits that reference this issue
on Aug 8, 2026 Draft implementation checkpoint: PR #400 now resolves one root-local RuntimeBinding, carries exact runtime payload identity, validates stored ELF closure facts, and keeps SubOS selection non-transitive. Focused RuntimeBinding/ELF tests and E2E #200/#205/#206 pass locally. This issue remains open because closure requires a reviewed merge and released-binary validation, not source-only evidence.
- added a commit that references this issue
on Aug 9, 2026 2026.8.10.1已发布（PR #400，合入 commit0006ce6），本 issue 报告的两条都有对应实现，
但我不在这里关闭它——原因写在最后。已经落地的部分
- 私有 glibc 按精确身份解析：
glibc@2.44只解析<xpkgs>/xim-x-glibc/2.44/{lib64,lib}。
精确 payload 缺失或陈旧就是错误，绝不从多个已安装版本里挑「看起来能用的第一个」。 - 链接后 Rule A / Rule B 闭包校验（Build-time physics check for form-X binaries (rules A/B): fail at link time instead of crashing at run time #396）：解释器、直接与传递 libc 必须与同一个
RuntimeBinding 一致，宿主 DSO 的GLIBC_*需求不得越过选中 libc 的 export floor。
失败发生在链接时，而不是运行时崩溃。 mcpp run不再把私有 glibc 泄漏给子进程（Bug: 私有 glibc 2.44 的 libc.so.6 引用 loader 私有符号__pointer_chk_guard，mcpp run 下子进程(/bin/sh)必死 #401）：那条环境项本来就没有收益
（产物 RUNPATH 早就覆盖了它，删掉前后逐字节相同），却会杀死每一个由宿主 loader
加载的后代进程。
为什么不关
本轮做图形栈验收时，把
<subos>/lib放进LD_LIBRARY_PATH又原样复现了同一族崩溃：$ LD_LIBRARY_PATH=<subos>/lib timeout 600 mcpp run timeout: symbol lookup error: <subos>/lib/libc.so.6: undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE也就是说：mcpp 侧的出口已经堵上了，但「私有 glibc 与宿主 loader 相遇即死」这个物理
事实仍然存在，只要有任何一条路径把那个目录送进环境就会重现。真正的根治在 xlings 侧
（让私有 glibc 自包含，或者让需要它的消费方走 RPATH），已作为
openxlings/xlings#525 的证据记录。本 issue 的症状是环境相关的。请在
2026.8.10.1上复核你原来的场景；确认之后再关，
比我替你宣布修好了更可靠。- 私有 glibc 按精确身份解析：
- added a commit that references this issue
on Aug 10, 2026 2026.8.10.2已发布。本 issue 我仍然不在这里关闭 —— 理由在最后。这一版新增的、与本 issue 同一族的部分
-
mcpp pack的自带 libc 档不再接受宿主能力。--mode self-contained与
--mode static在解析后的图里存在 run 期能力需求时,在 plan 期失败并指出
改用--mode vendored。两者坏在同一件事上,正是本 issue 记录的物理:
那个.so带着对宿主 libc 的要求进来,而进程里没有那份。
此前两档都链得过去、然后运行时崩或静默降级。 -
打包产物不再残留构建机路径。 此前只重写主二进制,bundle 进来的每个
.so
都保留着指向构建机 xlings store 的绝对 RUNPATH。 -
加载器标签契约:可执行文件 DT_RPATH、共享库 DT_RUNPATH,链接期与 patchelf 期
同一条契约,并在resolution.json留loader_tags记录。
为什么还不关
本 issue 的症状是环境相关的,而且我这台机器验不了它 ——
它的共享 gcc 载荷 specs 已被历次安装污染(--dynamic-linker指向一个已被改名走的
glibc/2.44),这本身就会以本 issue 描述的方式失败,与 mcpp 的版本无关:
已发布的2026.8.8.2在同一台机器上复现同样的症状。请在
2026.8.10.2上复核你原来的场景。 你确认之后再关,比我替你宣布修好了可靠。真正的根治(让私有 glibc 自包含,或让消费方走 RPATH)仍在
openxlings/xlings#525。-
- added a commit that references this issue
on Aug 27, 2026
环境
现象
mcpp run 静默退出，exit 1：
sh: /home/farna/.mcpp/registry/data/xpkgs/xim-x-glibc/2.39/lib64/libc.so.6: version `GLIBC_2.42' not found (required by /lib64/libtinfo.so.6)
用 ./run.sh（显式用系统 /lib64/ld-linux-x86-64.so.2 启动）可正常运行 → 问题定位在 mcpp 私有 glibc 与系统库不兼容，而非应用代码。
根因
-B…/xim-x-glibc/2.39/lib64
-L…/xim-x-glibc/2.39/lib64
-Wl,--dynamic-linker=…/2.39/lib64/ld-linux-x86-64.so.2
-Wl,-rpath,…/2.39/lib64
-isystem …/2.39/include
修复：切到 glibc 2.44
2.44 > 2.43 > 2.42，私有 libc 自身满足全部系统库要求 → mcpp run 原生可启动。
改动（都在 ~/.mcpp / ~/.xlings，仓库代码零改动）：
"glibc@2.44"。解析层据此更新（.xlings-resolu4，subos lib 软链 crt1.o/ld-linux/libc.so.6等全部指向 2.44）。
机制发现（重点，建议 mcpp/xlings 侧跟进）
metic fixup 的 glibc 选择不读取 resolver 记录，而是扫描 xim-x-glibc/ 目录取"字典序第一个"版本目录，用它重新生成 clang.cfg 与 .mcpp-fixup.json。
实证链：
后果：只要 registry 里存在 2.39，无论 subos runtime 怎么配，clean build 后 toolchain 都会悄悄回到 2.39。建议 fixup 优先采用 resolver 的版本选择，或至少按语义化版本（而非字典序）排序。
切换后的状态与副作用
次测试稳定存活）；aria2 引擎走 posix_spawn， 。
建议