Skip to content

docs(xim): one question, four answerers — a design that removes the divergence - #484

Closed
Sunrisepeak wants to merge 1 commit into
mainfrom
docs/dep-resolution-design
Closed

docs(xim): one question, four answerers — a design that removes the divergence#484
Sunrisepeak wants to merge 1 commit into
mainfrom
docs/dep-resolution-design

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Adding a second glibc turned a latent structural fault into binaries that segfault before main with no diagnostic.

The fault is not multi-version coexistence — that is what the design allows. It is that one consumer got its INTERP from one payload and its RUNPATH from another, because "which version is this dependency" is answered independently in four places, and glibc declares loader but not libdirs so its two halves travel two different channels. Those halves are not separable: the measured failure is undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE.

Both directions reproduced in an isolated home. The agreement everyone relied on is coincidence — it breaks as soon as pin_target_to_active makes the resolver prefer a lower version than the scan does, which is why the libxpkg 0.0.49 fix is a workaround by the doc's own criterion.

The proposal is a net deletion: record the resolved dep totally (its install_dir is already computed and discarded by a break), make dep_install_dir a lookup, delete elfpatch's re-derivation branch, and assert loader/libdir same-source at install time. Plus .xlings-resolution.json + xlings why for traceability.

The assertion ships as an executable criterion already: FAILs the constructed divergence, zero false positives across 196 binaries in three ecosystems.

…ivergence

Adding a second glibc to the index turned a latent structural fault into
binaries that segfault before `main` with no diagnostic. This records the
fault precisely, why the fix already shipped is a workaround, and what
removing it properly looks like.

The fault is not "two glibc versions in one home" — that is what the design
allows and recommends, since consumers reference payload paths directly and
two applications in one subos may legitimately want different ones. It is
that ONE consumer got its INTERP from one payload and its RUNPATH from
another, because "which version is this dependency" is answered independently
in four places:

  R1  the resolver's plan node — authoritative, and discarded by a `break`
      for any dep that declares no exports
  R2  a directory scan in libxpkg
  R3  the xvm active version
  R4  a {lib64, lib} convention re-derivation in elfpatch

glibc declares `loader` but not `libdirs`, so its two halves travel two
different channels. The halves are not separable: the measured failure is
`undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE` — the private
ABI between ld.so and libc.so.6.

Both directions of the divergence were reproduced in an isolated home, and
the table in §3 shows the agreement everyone has been relying on is
coincidence, not a guarantee: it holds while the resolver and the scan both
pick the highest version, and breaks the moment `pin_target_to_active` makes
the resolver prefer a lower one.

The proposal is a net deletion rather than a fifth answerer: record the
resolved dep totally (the install_dir is already computed and thrown away),
make libxpkg's dep_install_dir a lookup, delete elfpatch's re-derivation
branch, and assert at install time that a provider's loader and its libdir
come from the same payload.

The assertion is not left as prose. `.agents/tools/check-loader-libc-same-source.sh`
implements it now: it FAILs the constructed divergence, passes the healthy
package, and reports zero false positives across 196 binaries in three
installed ecosystems. Zero false positives is what makes it fit to become a
doctor rule — a check that cries wolf gets skipped, and a skipped check is
the same as no check.
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.

1 participant