[bug] nasm 惰性自举时序:构建先于 bootstrap 完成而判死(.asm 冷环境必失败)

[Sunrisepeak]

现象(mcpp 0.0.95,linux CI 冷 sandbox,两次复现)

含 .asm 的包(compat.ffmpeg)在冷环境构建时,nasm 惰性解析报错先于自举消息打出:

22:29:18.92 error: NASM sources (.asm) present but no usable nasm (>= 2.16) was found or installable; install one via `xlings install nasm` or your system package manager
22:29:19.16    Bootstrap nasm into mcpp sandbox (one-time)

两轮独立 run(29617083414 首跑与 failed-rerun)时序完全一致:错误 → ~0.25s 后 bootstrap 启动 → 构建已判死。即 “Bootstrap nasm (one-time)” 被触发,但发起它的构建不等待/不重试,冷环境 100% 失败;PATH 上有 nasm 时不受影响。

复现

mcpp-index PR #74 的 workspace (linux) job(移除 apt nasm 后,13aa71d):

• run: https://github.com/mcpplibs/mcpp-index/actions/runs/29617083414

期望

nasm 解析链(PATH → sandbox → bootstrap)中,bootstrap 应同步阻塞当前编译边(或 bootstrap 完成后重试该 TU),像 gcc 工具链自动安装那样;而不是先判死再后台补装。

附带观察

CI 的 actions/cache 精确命中时跳过保存,bootstrap 产物不会进缓存——即使自举成功过,下个 run 仍是冷启动;修复以同步阻塞为准而非依赖缓存。

[Sunrisepeak]

补充:本地复现把根因往下挖了一层 —— 不是时序问题,是 xim:nasm 安装本身产出空载荷。

ensure_nasm(src/xlings.cppm)是严格同步的:PATH 探测 → 阻塞式 install_with_progress(env, "xim:nasm") → 重新 find_sandbox_nasm → 全空才报错。日志里 error 先于 "Bootstrap nasm" 出现只是 ui 缓冲交错(status 走缓冲通道、error 直写),不存在"先判死后补装"的竞态。

真正的断点(本地 100% 复现,linux x86_64):

export XLINGS_HOME=<fresh-dir>            # 从 mcpp-0.0.95-linux 发行包拷贝 registry
<vendored>/bin/xlings install xim:nasm -y  # 输出 ✓ 1 package(s) installed,rc=0

之后:

• data/xpkgs/xim-x-nasm/3.02/ 只有 .xim-installed + .xpkg.lua,没有 nasm/ndisasm 二进制;
• subos/default/bin/nasm shim 已创建但悬空(nasm -v 无输出);
• 所以 find_sandbox_nasm 探测 <ver>/nasm、<ver>/bin/nasm 找不到是正确行为 —— 载荷根本不存在。

嫌疑机制:xim-pkgindex pkgs/n/nasm.lua 的 hook

function install()
    os.tryrm(pkginfo.install_dir())
    os.mv("nasm-" .. pkginfo.version(), pkginfo.install_dir())
    return true
end

与新版 xlings 安装器的 C++ 侧 stage_extracted_payload_(下载解压后自动把载荷搬进 install_dir)叠加:C++ 先 staged → hook 的 os.tryrm 把已就位的载荷删掉 → cwd(runtimedir)里 nasm-3.02 已被搬走,os.mv 落空 → 仍返回 true → xlings 标记安装成功并建 shim。

建议修复方向(择一或并行):

1. xim-pkgindex:nasm.lua 的 install() 改为幂等(载荷已在 install_dir 时直接 return true),这是最小改动;同类 "tryrm+mv" 手写 hook 的包需要排查。
2. xlings:hook 返回 true 但 install_dir 为空(或 xvm shim 指向不存在的 bindir)时判失败,别让空安装标记成功——这是防同类问题的系统性修法。
3. mcpp ensure_nasm:find_sandbox_nasm 复查失败时把 xlings install 的输出转发出来,别只留一句 "not installable"。

另:CI 侧 mcpp-index 已恢复 apt nasm(f2f7e08)作为临时措施,此 issue 修复后即可移除。

[Sunrisepeak]

Root cause confirmed (supersedes my earlier hook-vs-staging theory)

The empty install is an index-side descriptor bug, now fixed in openxlings/xim-pkgindex#398:

nasm.lua (from xim-pkgindex#395) declared its resources with the new xpm.source = "xlings-res" + per-arch sha256 table form. Deployed xlings engines parse neither the source key nor a table-valued sha256 — the resolved resource ends up with no URL, so no download is ever planned. Reproduced with the xlings vendored in mcpp 0.0.95 (fresh XLINGS_HOME, verbose): no Download/Extract phase, runtimedir/ empty, then:

1. install hook runs: os.mv("nasm-3.02", install_dir()) — source dir doesn't exist, no-ops; hook still return true
2. xlings auto-stamps .xim-installed into the empty dir → "1 package(s) installed ✓"
3. config() registers xvm shims pointing at nothing → dangling subos/default/bin/nasm

Fix landed (index side): xim-pkgindex#398 switches nasm.lua to the production-proven mcpp.lua idiom — url = "XLINGS_RES" placeholder + arch-keyed sha256 (ignored by old engines, verifiable by new ones) — and hardens install() to be idempotent and to fail loudly when the binary isn't in place instead of returning true over an empty dir. Verified against the vendored 0.0.95 xlings: download happens, nasm --version → 3.02.

Remaining mcpp-side gap (why 0.0.96 is still affected out-of-the-box)

ensure_nasm calls install_with_progress(env, "xim:nasm", ...) directly, with no index-freshness call — and even ensure_official_package_index_fresh wouldn't help here: it is offline-first and returns early when the package file exists locally. The xim-pkgindex snapshot vendored inside the mcpp 0.0.96 release archives predates the fix, so the broken nasm.lua is used as-is until the user happens to run xlings update / mcpp index update.

Suggestions:

• next mcpp release: vendor a post-#398 index snapshot (sufficient by itself);
• more robust: when a bootstrap install reports success but the sandbox probe (find_sandbox_nasm) still finds nothing, force one index refresh and retry once — that would have both surfaced and healed this failure mode;
• xlings: refuse to auto-stamp .xim-installed over an install whose hook moved nothing and whose download plan was empty (a package with programs declared but an empty install dir is almost certainly a failure, not a wrapper package).

CI note: mcpp-index keeps its apt-get install nasm step until a mcpp release ships with the fixed vendored snapshot.

[Sunrisepeak]

✅ 已在 mcpp 0.0.97 修复(PR #236,482b428,簇 F)。

nasm 供给改走工具链同款同步门 Fetcher::resolve_xpkg_path("xim:nasm@3.02", autoInstall=true)(索引刷新前置 + 阻塞安装 + payload 校验 + 硬报错),不再先判死后台补装;get_cfg() 的 config 自举错误不再被吞成误导性的 "no usable nasm"。

验证:单测(find_usable_nasm 6 例矩阵 + 错误不吞)+ e2e 105_asm_sources_nasm.sh 冷环境分区。