Rpath with $ORIGIN fools snapcraft library bundling mechanism
Metadata
Current evaluation
Snapcraft incorrectly expanded $ORIGIN in rpath to absolute paths, breaking library bundling. The issue was fixed and verified, preserving $ORIGIN correctly during snap builds.
Suggested action: —
No scores available.
Issue body
I have a pre-built binary game using rpath with "$ORIGIN/lib64". Snapcraft expands that to $(pwd)/lib64 (eg /home/zyga/blah/blah/blah/lib64) and a directory like that is added to the snap. At runtime the rpath is still as before so the library cannot be found.
[Impact]
* Wrong paths end up in the snap, which makes it to fail.
[Test Case]
* Make a snap wit $ORIGIN in rpath.
* Run snapcraft
* Install it and execute it.
[Regression Potential]
* This affects the files that end up in the snap. Many scenarios are covered by tests, but some exploratory would be good.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.6-35b-a3b | — | — | Snapcraft incorrectly expanded $ORIGIN in rpath to absolute paths, breaking library bundling. The issue was fixed and verified, preserving $ORIGIN correctly during snap builds. | |
| qwen/qwen3.6-35b-a3b | — | — | Fixed and verified. Snapcraft incorrectly expanded $ORIGIN in rpath to absolute paths, breaking library bundling. Resolution preserves $ORIGIN during snap building to ensure correct runtime library resolution. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1896 elf: do not strip rpaths that contain $ORIGIN | snapcraft | merged | Merged to preserve ELF rpaths containing $ORIGIN during stripping. This allows custom runtime library paths that snapcraft would otherwise fail to resolve. Approved by reviewer and passed CI checks. |