Repository navigation
fix(elfpatch): keep shared payload closures independent of SubOS scopes - #47
Merged
Merged
Conversation
Prepare the package version for review. Publication remains pending approval and platform release assets.
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.
Shared package payloads are reused by multiple SubOS scopes, but
elfpatch.closure_lib_paths()appended the installing scope’slibdirectory to their RPATH. This froze one scope into shared binaries and caused PR #641’s exact root-closure validation to reject Luban core libraries.Return only the package’s own library directories and its resolved runtime dependencies. Keep dependency overrides and build-dependency exclusion intact.
Validation: the new regression fails on the previous implementation for both scopes, showing the injected scope path. After the fix, all four local test programs pass; all 97 executor cases pass. Joint static xlings validation creates a fresh Luban core and runs GCC to compile and execute a C program successfully. The dependency fix is proposed separately for review; PR #641 will not be merged or released without the maintainer’s review.
Refs: openxlings/xlings#641
Candidate version:
0.0.62. After the version bump, all four local test programs pass again (97 executor cases). A local Linux clang22/libcxx22 release package builds successfully; SHA256d87c2bd7891ad76dc85b9c631c52fe85d0663371b5f130d201cb47fe00362ccc. The existing index distributes one source archive across Linux, macOS and Windows; formal source-tag publication, mirroring and three-platform index updates remain pending. The precompiled Linux archive is supplemental build evidence. No merge or release has been performed.Candidate head CI: https://github.com/openxlings/libxpkg/actions/runs/37804601384 passed. The new
Elfpatch_ClosureRemainsPayloadDirectAcrossScopesregression actually ran and passed. This existing workflow excludesExecutorTest.ApplyElfpatchAuto_*; 89 executor cases ran in CI, while all 97 ran locally.