handling interpreters in *-snapper scripts (or snapcraft)

[Zygmunt Krynicki]

Without mandating shared library layout you will force everyone to use
shell scripts to identify this and compensate. I think this is a
mistake, all platforms define how shared library lookup works. Unless
you expect that all snappy apps will use static linking and go. There
is nothing wrong with specifying basic stuff.

Thanks
ZK

On Mon, Jun 15, 2015 at 4:25 PM, Ted Gould <ted at ubuntu.com> wrote:
> On Mon, 2015-06-15 at 14:03 +0200, Zygmunt Krynicki wrote:
>
> As an example, to get lxml (pip installable) working you need to
> bundle a few extra libraries that are _not_ handled by anything on the
> python side (no tool automates this). I build a smap with plainbox
> manually by using rpath to show each of the .so files that python
> loads where to load remaining libraries from. It would be very
> beneficial if LD_LIBRARY_PATH was defined by snappy launcher so that
> rpath is not required.
>
>
> I don't think that the launcher can really set that, as we don't know
> exactly what it would be for the particular package. Otherwise we start to
> put in magical directory layout things for snaps, which make them harder to
> build.
>
> An idea that has been bouncing around is to provide a global environment
> setup script for executing in a snap that perhaps could be used for
> something like this. You can imagine for instance that the LD_LIBRARY_PATH
> could change depending on architecture for a multi-arch snap.
>
> Ted
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>