Skip to content

The declared C runtime is installed before the fixup consumes it; the lookup is exact (#660) - #663

Merged
Sunrisepeak merged 1 commit into
mainfrom
fix/declared-runtime-is-installed
Sep 17, 2026
Merged

Sunrisepeak merged 1 commit into
mainfrom
fix/declared-runtime-is-installed

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Summary

Closes #660.

Cause. The default SubOS declares its glibc by exact version (glibc@2.44.3) and the toolchain fixup patches against xim-x-glibc/<version>, but no step installed that payload. The two loops meant to do it (lifecycle.cppm, first-run in prepare.cppm) passed xim:glibc without a version; Fetcher::resolve_xpkg_path rejects such a target and the rejection was logged at debug level and discarded (mcpp -v shows installing dep: xim:glibc followed by no fetcher line). The payload therefore existed only when xlings installed it as a dependency of a toolchain. A toolchain restored from a CI cache is not reinstalled, so a cache holding another glibc revision left the declared payload absent. The 2.44.x refinement scan in payload_dir_for_version concealed this until two revisions coexisted, which xim-pkgindex#852 (glibc 2.44.3) produced.

Measured with the released 2026.9.15.1 and xlings 2026.9.14.1: a cache-shaped store (gcc payload present, glibc 2.44.2 present, 2.44.3 declared) fails at the first fixup; upgrading xlings alone does not fix it.

Change.

  • ensure_declared_runtime installs xim:glibc@<declared> through xlings and re-resolves the binding. It runs once, before the first fixup that consumes a C runtime (post_install_fixup_kind non-empty: gcc and llvm payloads), only on Linux, only for the glibc provider, and only when the binding locates no payload. A home in its normal state starts no process; system, musl and PE toolchains download nothing. A failed install is not fatal at that point; the fixup reports the absence with the coordinate xim:glibc@<version>.
  • The lookup is exact: select_glibc_payload_lib and probe's payload_root_for_binding accept only xim-x-glibc/<version>. payload_dir_for_version and the now-unused needs_linux_sysroot_payloads are removed.
  • The xlings released beside the mcpp executable (<prefix>/registry/bin/xlings) is an acquisition source ahead of the PATH. An mcpp installed as an xlings package uses ~/.mcpp and previously kept an older PATH xlings with a note.
  • Docs: docs/91-toolchain-internals.md (en/zh) states who installs the exact payload. CHANGELOG. Analysis and plan records in .agents/docs/2026-09-17-*.
  • Version 2026.9.17.2.

Test plan

  • mcpp test: 121 passed (new GlibcPayload.*, DeclaredRuntime.*)
  • e2e 737 (new): fresh install, reduce the home to a CI cache shape, rename the declared glibc; offline build fails naming xim:glibc@<v>, online build installs it and runs, toolchain install likewise. Green on this build; red on released 2026.9.17.1 with the toolchain post-install fixup: glibc@2.44 binding cannot resolve after 2.44.3 was published (every clean machine fails) #660 message.
  • e2e 687 leg C (new): release layout replaces an older vendored xlings with no override and a reduced PATH. Green here; red on 2026.9.17.1.
  • e2e 01, 237, 26 green locally
  • check_docs_style.sh, check_docs_structure.sh, check_version_pins.sh
  • CI

… lookup is exact (#660)

The default SubOS declares its glibc by exact version and the toolchain fixup
patches against the payload directory of that version, but no step installed
that payload. The two loops meant to do it passed `xim:glibc` without a
version, which `Fetcher::resolve_xpkg_path` rejects, and the rejection was
logged at debug level and discarded. The payload was present only when xlings
installed it as a dependency of a toolchain; a toolchain restored from a CI
cache is not reinstalled, so a cache holding another glibc revision left the
declared payload absent. A directory scan that accepted any `2.44.x` for
`2.44` concealed this until two revisions were present at once.

- `ensure_declared_runtime` installs `xim:glibc@<declared>` through xlings and
  re-resolves the binding. It runs before the first fixup that consumes a C
  runtime (gcc and llvm payloads), only on Linux, only for the glibc provider,
  and only when the binding locates no payload.
- `select_glibc_payload_lib` and `probe` look up the exact version only;
  `payload_dir_for_version` and `needs_linux_sysroot_payloads` are removed. A
  missing payload is reported with the coordinate that provides it.
- The xlings released beside the mcpp executable is an acquisition source
  ahead of the PATH.
- Unit tests `GlibcPayload.*`, `DeclaredRuntime.*`; e2e 737 (cache-shaped home,
  offline and online) and e2e 687 leg C. Both e2e are red on 2026.9.17.1.
- Version 2026.9.17.2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

toolchain post-install fixup: glibc@2.44 binding cannot resolve after 2.44.3 was published (every clean machine fails)

2 participants