feat(xim): wire exports schema + predicate-driven elfpatch trigger#253
Merged
Sunrisepeak merged 3 commits intomainfrom May 2, 2026
Merged
feat(xim): wire exports schema + predicate-driven elfpatch trigger#253Sunrisepeak merged 3 commits intomainfrom
Sunrisepeak merged 3 commits intomainfrom
Conversation
Companion to mcpplibs/libxpkg's exports schema addition. PlanNode gains an `exports` field (mirroring libxpkg ExportsRuntime shape, kept in xlings's namespace to avoid dragging the upstream header into every TU). Resolver populates it from pkg->xpm.exports[platform] in both IndexManager and PackageCatalog overloads. Installer extends ExecutionContext with runtime_deps_list, build_deps_list, deps_exports (per-runtime-dep slim export info), and self_exports — all paths pre-joined with absolute install_dir so the Lua side gets ready-to-use absolute paths. The deps_exports lookup walks plan.nodes to find the dep matching each runtime_deps spec (name + optional @Version), then composes loader/libdirs from THAT dep's install_dir. This is "Phase 1" per docs/plans/2026-05-02-elfpatch-exports-design.md: zero behavior change. Nothing reads the new fields yet — they're plumbed end-to-end so phase 2 (elfpatch.lua predicate trigger, already in libxpkg) can use them on the next libxpkg release. Validated locally: source compiles to link stage 93% against local libxpkg (--local_libxpkg=/path); link blocked by pre-existing env issue (ftxui static lib glibc/musl mismatch in xrepo cache), unrelated to these changes. CI three-platform will exercise actual link.
4 tasks
Sunrisepeak
added a commit
that referenced
this pull request
May 2, 2026
…tch (#254) Bumps VERSION from 0.4.10 to 0.4.11. Highlights since 0.4.10: * #253 — Declarative `xpm.<platform>.exports` package metadata, plus a predicate-driven elfpatch trigger that lets xlings auto-patch consumer ELFs based on what providers declare (rather than consumers hardcoding loader paths in their install hooks). Schema (provider side, all sub-fields optional): xpm = { linux = { deps = { runtime = {...}, build = {...} }, exports = { runtime = { loader = "lib64/ld-linux-x86-64.so.2", libdirs = { "lib64", "lib" }, abi = "linux-x86_64-glibc", }, }, ... }, } Only libc-class providers (glibc, musl) need to declare the `loader` field; `libdirs` defaults to the {lib64, lib} convention and need not be re-declared by 99% of packages. Consumer side: xlings reads runtime deps' exports after install and applies INTERP / RPATH automatically. The 4 existing consumers (binutils / openssl / gcc / d2x) keep working unchanged via the libxpkg deprecation alias for the legacy `elfpatch.auto({...})` API; they migrate to the new flow on a rolling schedule (xim-pkgindex follow-on PRs). Old API drop target: 2026-11. Internal layered fixes that came along for free: - `_RUNTIME.deps_list` was the runtime ∪ build union; new `runtime_deps_list` / `build_deps_list` split avoids build_dep lib paths leaking into consumer RPATH (latent bug from #249). - elfpatch's ELF target collector now checks `e_machine` so a package that ships both x86_64 and aarch64 binaries doesn't get all of them patched on whatever the host happens to be. - Static binaries (no PT_INTERP) skip the patchelf fork+exec round-trip. * libxpkg dependency bumped to mcpplibs-xpkg 0.0.33 (carries the schema parser + new elfpatch.lua API). * Design doc landed at docs/plans/2026-05-02-elfpatch-exports-design.md. Migration: 0.4.10 → 0.4.11 is binary-compatible. Existing xpkgs keep working through the legacy elfpatch deprecation alias. New behavior (predicate-driven auto-patch) only kicks in once a package declares `exports.runtime.loader` AND consumers stop calling `elfpatch.auto(...)` in their install hook — both are opt-in package metadata changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
xlings-side companion to openxlings/libxpkg#9.
PlanNodegains anexportsfield mirroring libxpkg'sExportsRuntimeshapenode.exportsfrompkg->xpm.exports[platform]in both IndexManager and PackageCatalog overloadsExecutionContextwithruntime_deps_list,build_deps_list,deps_exports(per-runtime-dep slim export info, paths pre-joined to absolute), andself_exportsThe new fields plumb metadata end-to-end so libxpkg's elfpatch.lua can do predicate-driven post-install patching (decision tree in libxpkg PR).
Detailed design: docs/plans/2026-05-02-elfpatch-exports-design.md (also shipping in this PR).
Why draft
This PR's xmake.lua needs to bump
add_requires("mcpplibs-xpkg 0.0.32")→"0.0.33"to actually compile, but 0.0.33 doesn't exist in mcpplibs-index yet. CI is therefore expected to be RED until:The companion xim-pkgindex PR (d2learn/xim-pkgindex#104) has been drafted and waits on this PR to merge first.
Validation already done locally
Joint local build (
xmake f --local_libxpkg=/path/to/libxpkg/checkout) compiles all source through link stage 93%. Link blocked by pre-existing local env mismatch (ftxui xrepo cache built against glibc, won't link with musl-static — same env issue as #249/#250/#251 had locally; CI doesn't have this issue).Test plan
readelf -l <binutils-bin>INTERP points at xpkgs glibc loaderBehavior change scope
Phase 1 only — the resolver/installer plumbing. No behavior change until the libxpkg-side elfpatch.lua predicate trigger activates, which only happens once add_requires is at 0.0.33 (post-merge of upstream PR). Existing 4 consumers in xim-pkgindex still call
elfpatch.auto({...})and continue to work via the deprecation alias (debug log only in verbose mode).