Snappifying a big toplevel program

Loïc Minier loic.minier at
Tue Feb 24 14:03:27 UTC 2015

On Mon, Feb 23, 2015 at 6:29 PM, Michael Terry <michael.terry at>

> Ouch.  LD_LIBRARY_PATH doesn't cover much, as I mentioned in my first
> email.  Libraries & scripts often call outside executables with a full
> path.  And any data files referenced by libraries/programs tend to have
> full paths determined at compile time too.  Which means relying on
> LD_LIBRARY_PATH or PATH doesn't buy you much.

It's indeed an issue at a large scale, but perhaps it's manageable if it
covers a limited subset of packages we change to take a configurable
runtime pathnames; would you know how many packages are we speaking of?

> What are the SNAPPY_* vars?  (Sorry for newbie questions, I'm coming into
> snappy rather fresh, and all the docs I've seen

here are some specific pathnames your app can use for persistence and which
are set in the environment:
- $SNAPP_APP_PATH contains the base of your installed app (typically static
- $SNAPP_APP_DATA_PATH contains the writable directory for your app
- there's also a per app, per user directory

> So maybe there is room for LD_PRELOAD path-redirection after all,
> especially if overlays are a no-go on the phone.  Unless there are
> objections that I'm wasting my time, I'm going to investigate that.

Yes; that could work. There are some limitations there too, but perhaps
it's a more sensible short-term approach when we control the programs
somewhat. I believe scratchbox2 or scratchbox-ng had a relatively generic
implementation with redirection rules in lua or some other high level
config/scripting language.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list