LD_LIBRARY_PATH hardcoded at snap creation time -- RPATH

[Loïc Minier]

Hi,

LD_LIBRARY_PATH currently includes triplet as computed at snap creation time, but it should rather be set at runtime on a per-architecture basis.

In fact, a better approach would be to set a RPATH relative to the binary: $ORIGIN/../../lib/$PLATFORM, or something like that.

Cheers,

[Leo Arias (elopio)]

Moved to https://github.com/ubuntu-core/snapcraft/issues/38

[Sergio Schvezov (sergiusens)]

From lool:

So today snapcraft generates small shell scripts to set the LD_LIBRARY_PATH.

First, it's only aware of the current architecture, and so it hardcodes the triplet based on the system the build is running on. Since snapcraft doesn't have support for cross-architecture builds yet, you might wonder what we would benefit from computing this at runtime instead of the current approach. This is typically a benefit if the upstream build process includes pre-built binaries or if you're invoking a cross-compiler in the upstream build process. e.g. if my snap is created by unpacking a pre-built java runtime from a tarball, snapcraft might not know about building binaries for this architecture, but the shell snippets setting LD_LIBRARY_PATH would work. This is currently achieved with something like:
case uname -m in
x86_64)
triplet=x86_64-linux-gnu
;;
armv7l)
...
esac

Alternatively, there is a possibly more elegant approach we could take, which would be to set the RPATH on the actual binaries. Basically snapcraft would put the libraries in the usual location and would run chrpath on the binaries ot set a relative library search path such as ../lib/triplet. This would be similar to how today the Python runtime searches for loadable site-/dist-packages relative to the python binary under the snap; or how snapcraft mangles symlinks which point out of the snap.

[Björn Michaelsen (bjoern-michaelsen)]

I wonder if RPATH could work in the general sense: Assume you have an application A build against library B which links against library C. A is build in snapcraft and set an RPATH in the build, but B and C are imported as packages from xenial and as such wont have a RPATH. Will B find C then?

Also note that this must work with upstreams setting their own RPATHs in their build system, e.g. http://opengrok.libreoffice.org/xref/core/solenv/gbuild/platform/unxgcc.mk#222

[Netphreak (netphreak)]

Any news on this?

- I see more people having the same issues.

[Samuel (samuel.deancos)]

I have a similar problem compiling and executing (rpi) for armhf:

Snap /carriotsctl/x1/usr/bin/python3: 1: /snap/carriotsctl/x1/usr/bin/python3: can not create ^ ^ X $ /lib64/ld-linux-x86-64.so.2GNU: Directory nonexistent

Maybe it's the same problem?

[Sergio Schvezov (sergiusens)]

This is no longer the case for core22