feat(xim): persist declared xpkg exports to .xpkg-exports.json#351
Merged
Conversation
…ts.json Packages can declare runtime metadata (xpm.<platform>.exports.runtime: loader / abi / libdirs — e.g. glibc declares its dynamic linker precisely so consumers don't hardcode 'lib64/ld-linux-x86-64.so.2'), and xlings already parses and uses it for elfpatch predicates. But the declaration was invisible ON DISK, so downstream consumers (mcpp's toolchain link model) had to re-derive the loader by convention (triple maps + globs). Persist it at install time in the declared RELATIVE form; consumers join against the payload root, so the file stays valid across copies and symlink inheritance. Idempotent, also written for already-installed payloads on their next resolve.
Sunrisepeak
added a commit
that referenced
this pull request
Jul 7, 2026
…kg-exports.json (#351)" (#352) The persisted file's only consumer was mcpp's toolchain link model, and the entire mcpp 0.0.83 verification matrix (PR CI, hermetic container, fresh installs across 3 platforms + 6 distro containers) ran green on xlings 0.4.62 — which never had this file — with mcpp's built-in fallback (per-arch triple map + glob) covering every real-world case. A general-purpose package manager should not carry a mechanism whose sole reader is one downstream tool: reverted per layering review. The declared exports in package lua (exports.runtime) are untouched — xlings' own elfpatch predicate still consumes those. If an installed-state metadata DB is ever needed, it should be designed with xlings itself as its first consumer.
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.
Companion to the hermetic toolchain link model work (mcpp-community/mcpp#196, mcpp issue #195).
glibc.lua declares
exports.runtime.loaderprecisely so consumers don't hardcode the loader path — but the declaration never reached disk, so consumers re-derived it by convention. This persists the declared exports (relative form) to<install_dir>/.xpkg-exports.jsonat install time. mcpp's loader resolver already treats this file as its highest-priority source and falls back to a triple map + glob without it, so this PR is non-blocking for the mcpp release train.Note: local build verification wasn't possible on this machine (pre-existing local toolchain-header issue affects clean main identically); relying on CI for the compile check.