fix(pkginfo): a dependency's version range was joined as a directory name - #33
Merged
Conversation
…name
`_scan_dir` located a dependency by `path.join(dep_root, dep_version)`. The
version half of a dep spec is an EXPRESSION — `>=2.38`, `^1.2` — so the join
produced `xpkgs/xim-x-glibc/>=2.39`, which is not a directory, the scan
returned nothing, and `dep_install_dir` fell back to whatever version the
workspace had ACTIVE.
Meanwhile xlings computes the interpreter from the version the RESOLVER chose.
With two versions of a package in one home those are different answers, and
for glibc specifically the result is a binary whose INTERP is one glibc and
whose RUNPATH is another. It segfaults before `main`, with no diagnostic,
because each half is individually correct.
Reproduced from an empty home in one command:
xlings install glibc mesa gcc
→ glibc 2.39 (bare request → latest) and 2.44 (mesa's >=2.38) both install
→ gcc: INTERP=2.44, RUNPATH=2.39, Segmentation fault
The exact name is picked first, so a recipe that pins is unaffected and a
version string that is not semver at all — a date, a git hash — still matches
itself. Otherwise the highest INSTALLED version satisfying the expression is
chosen, which is the same rule the resolver applies: these two have to agree,
and agreeing is the whole point.
`_version_satisfies` handles the operators the resolver supports and returns
false for anything it does not understand, so an unrecognised expression falls
through to the previous behaviour rather than matching something arbitrary.
Same root cause as xlings 2026.8.5.2's installer fix — a range compared as a
literal — in the second place it lived.
Sunrisepeak
added a commit
to mcpplibs/mcpp-index
that referenced
this pull request
Aug 5, 2026
* feat(xpkg): 0.0.49 Dependency version ranges in a recipe were joined as directory names, so a consumer's RUNPATH and its INTERP could come from different versions of the same package — a binary that segfaults before main with no diagnostic. See openxlings/libxpkg#33. Published to both mirrors and verified byte-identical. * style(xpkg): keep the version list descending
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
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.
_scan_dirdidpath.join(dep_root, dep_version)with a version expression, producingxpkgs/xim-x-glibc/>=2.39— not a directory — so the scan found nothing anddep_install_dirfell back to the workspace's ACTIVE version, while xlings computed the interpreter from the version the RESOLVER chose.With two versions of glibc in one home those disagree, and the result is a binary whose INTERP is one glibc and whose RUNPATH is another. It segfaults before
mainwith no diagnostic, because each half is individually sane.Reproduced from an empty home in one command —
xlings install glibc mesa gcc— and verified fixed with the same command.Exact names still match first, so pinned recipes and non-semver versions are unaffected. Same root cause as xlings 2026.8.5.2's installer fix, in the second place it lived.