← Back to issue list

LD_LIBRARY_PATH values are inconsistent when working with others

View original Launchpad issue

Metadata

Project
snapcraft (launchpad)
Number
#1642041
Type
issue
State
closed
Author
~sergiusens
Labels
—
Created
Updated
Closed

Current evaluation

Closed as stale after builder-dependent runtime LD_LIBRARY_PATH entries caused inconsistent wrappers; a custom wrapper workaround was used, with no verified Snapcraft fix recorded.

Resolution: closed stale

Reason: The closing maintainer comment states, "Closing as stale." Discussion ended with a project-side wrapper workaround, and no resolving PR or commit was identified.

Evaluated by: mr-cal-bot

No scores available.

Issue body

Here's my situation: Some coworkers and I are working on a unity8-session snap. We have a silo with some fixes and it's connected to a snap recipe that builds the occasional on-demand snap. The snap is supposed to be built with xenial+overlay+silo. I was seeing some inconsistent behavior with other people that built their own snap. And I was seeing inconsistent behavior with other people that downloaded the silo snap. It turns out that snapcraft inserts some LD_LIBRARY_PATH values in the command-*.wrapper scripts based on how the build system is set up. (right?) Those differences between coworkers and the silo meant that some things were broken based on whose snap was being used, despite everything else being the same. Needless to say, that's annoying. Ideally we'd all be building "clean" snaps (as close to silo as possible). There's a "snapcraft cleanbuild" option. I'm not super familiar with it, but I'm guessing it would take some manual work to configure the lxd instance with xenial+overlay+silo. And might be harder to iteratively build too? Another option would be to let us build a snap without the special wrapper sauce? Or maybe just making sure that stage-packages are also used as build-packages (so that the silo build would also know about the extra LD_LIBRARY_PATHs from the system)? I'm not sure what the solution is necessarily. And I'm not even sure I've accurately diagnosed the problem. But the inconsistent experience felt annoying for a packaging format that is supposed to smooth out system differences.

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha — closed stale Closed as stale after builder-dependent runtime LD_LIBRARY_PATH entries caused inconsistent wrappers; a custom wrapper workaround was used, with no verified Snapcraft fix recorded.
stealth/space-bunny-alpha — closed stale Closed as stale by mr-cal on 2026-07-23; the discussion ended with a project-side wrapper workaround and no verified Snapcraft fix.
stealth/space-bunny-alpha — closed stale LD_LIBRARY_PATH report was abandoned without a fix: LP #1642041 closed with no recorded workaround, maintainer comment, or resolving commit.
qwen3.6-35b-a3b-mtp-q6 — — Abandoned. The report highlights inconsistent LD_LIBRARY_PATH values in snap wrapper scripts across different build environments, causing runtime discrepancies. No fix or workaround was implemented.
qwen/qwen3.6-35b-a3b
Staleness: 98
Complexity: 45
Confidence: 90
Support Request: 15
close stale Inconsistent LD_LIBRARY_PATH values in snapcraft wrapper scripts cause build discrepancies across developer environments. Untriaged, inactive for nearly a decade.
qwen/qwen3.6-35b-a3b
Staleness: 98
Complexity: 30
Confidence: 90
Support Request: 20
close stale Reports inconsistent LD_LIBRARY_PATH values in snapcraft wrapper scripts during collaborative builds. Unlabeled, zero comments, and inactive for nearly a decade. Snapcraft's build system and wrapper generation have been completely redesigned since then.
qwen3.6-35b-a3b-mtp-q6
Staleness: 98
Complexity: 45
Confidence: 90
Support Request: 75
close stale Inconsistent LD_LIBRARY_PATH values in snapcraft wrapper scripts cause build discrepancies across developers. Issue is over 9 years old with no maintainer response or labels.

Update history

Date Change
created

Related issues

Issue Project State Summary Similarity
#2128 project_loader: stop setting LD_LIBRARY_PATH snapcraft closed Closed unmerged in #2128 as unnecessary after the last known Trusty classic-snap user moved to Xenial; no code was changed.
72%
#1486623 LD_LIBRARY_PATH hardcoded at snap creation time -- RPATH snapcraft (launchpad) closed Hardcoded LD_LIBRARY_PATH behavior was declared obsolete: a maintainer said in 2023 that it no longer applies to core22; discussion had moved to canonical/snapcraft#38.
70%