Repository navigation
全新 MCPP_HOME 的首次构建:rule B 对每个产物报 inconclusive(binding 求值早于 farm 落盘) #417
Description
现象
在一个全新的 MCPP_HOME 里第一次构建(即用户装完 mcpp 的第一次 mcpp run),
runtime closure 校验对每一个产物报 inconclusive,刷出一屏警告:
warning: runtime closure validation is inconclusive for …/bin/helloegui:
rule B inconclusive for …/bin/helloegui: RuntimeBinding glibc@2.44 has no loader path
rule B inconclusive for …/bin/helloegui: RuntimeBinding glibc@2.44 has no library directory
warning: runtime closure validation is inconclusive for …/bin/libX11.so:
rule B inconclusive for …/bin/libX11.so: RuntimeBinding glibc@2.44 has no library directory
…（一个图形工程 13 条）
第二次构建警告全部消失。 这不是随机的:
binding.loader |
binding.library_dirs |
警告 | |
|---|---|---|---|
| 首次运行(同时在装工具链) | "" |
[] |
13 条 |
第二次 mcpp build |
…/xim-x-glibc/2.44/lib/ld-linux-x86-64.so.2 |
[…/xim-x-glibc/2.44/lib] |
无 |
复现:rm -rf 一个全新的 MCPP_HOME(或解包 release tarball 后直接构建)即可。
分析
src/platform/runtime_binding.cppm:337-380 从 <subos>/lib64、<subos>/lib 里找
libc.so.6 和唯一的 ld-linux-* 来填这两个字段。磁盘上二者都在
(<subos>/lib/libc.so.6 符号链接 + 唯一一个 ld-linux-x86-64.so.2),而
binding.search_dirs 也确实记下了 <subos>/lib —— 只有 loader / library_dirs
是空的。
自然的读法是:首次运行时 binding 的求值早于 farm 落盘。精确接缝(binding 解析点
vs 载荷/farm 写入点)还需要一次探针确认 —— 不要照着这个推理直接改。
影响
- 新用户的第一次构建就看到一屏自己无法处理的警告
- rule B 恰好在最该生效的那一次运行里失效
必须说清楚的一点
即使 rule B 完全正常,它也抓不到 #414 那个崩溃。
src/platform/elf_runtime.cppm:761-801 只比对 libc / PT_INTERP 的同一性,不管其它
SONAME 解析到谁。修这个 issue 不能替代 #414 的顺序修复,也不要把它当成那次缺陷的
兜底。
判据
全新 MCPP_HOME 的第一次构建:要么 rule B 给出真实判决(pass/mismatch),要么
binding 明确记录"此刻还无法求值"并只说一次,而不是对每个产物各刷两条。
背景
- rule B / RuntimeBinding 引入: feat: 运行期搜索闭包 与 binding 降级 —— 链接期看得见的,运行期也要看得见 (2026.8.11.2) #413
- 相关分析:
.agents/docs/2026-08-11-runtime-search-origin-precedence-analysis.md§4 D
Activity
docs: 七个 issue(#412 #415 #416 #417 #418 #421 #422)的逐条核实与修复方案
fix(runtime): #417 — a binding that cannot be evaluated is ONE fact, …
feat(bench): cross-platform benchmark suite, and the defects it expos…
speak-agent commentedon Sep 20, 2026
Fixed, and verified against
origin/main(05d03cd).The criterion this issue asked for was: on the first build in a fresh
MCPP_HOME, either rule B gives a real verdict, or the binding records that it cannot be evaluated yet and says so once — rather than two lines per artifact.That is what
src/build/runtime_validation.cppm:691-700now does. Before the per-artifact loop:The comment above it keeps the two decisions the issue asked to be kept apart: the root cause (binding evaluation ordering versus farm landing) is explicitly recorded as not settled, and rule B is still run rather than suppressed, because it has another input —
PT_INTERPidentity — and silencing it entirely would trade the screenful of noise for a blind spot. That is the half of the criterion that does not depend on the root cause, and it is the half this issue was filed for.Closing. The ordering question itself is a separate matter and has no open symptom.