LD_LIBRARY_PATH not set via a wrapper anymore?

[Patrick Boettcher]

I'm replying on Yann's behalf (for the moment).

On Tue, 17 May 2016 12:09:37 -0500
Didier Roche <didrocks at ubuntu.com> wrote:

> Le 17/05/2016 10:56, Yann Sionneau a écrit :
> > Hello,  
> Hey Yann,
> 
> > I noticed that a few weeks(?) ago, ubuntu-core-launcher was not
> > running directly the target binary, but instead was running a shell
> > script exporting PATH and LD_LIBRARY_PATH allowing to run binaries
> > from inside the snap and also
> > allowing to use shared libraries from inside the snap.
> >
> > But now it seems ubuntu-core-launcher directly runs the target
> > binary. How is this supposed to work with regard to shared
> > libraries from inside the snap?  
> 
> Hum, this isn't what I'm experiencing locally on my 16.04 LTS desktop
> using snap + snapcraft.

Here is what we did, basically - using an example project:

(inside a tmp-dir)

  git clone https://github.com/pboettch/example-project-for-snappy.git
  mkdir build
  cd build
  cmake -DCMAKE_INSTALL_PREFIX=`pwd`/../root \
        ../example-project-for-snappy
  make install
  snapcraft snap ../root

In reality we did some cross-compilation for armhf (raspi2, hence the
commented archictecture armhf). Installing this snap on the target
created a wrapper-script which was not setting LD_LIBRARY_DIR.

In fact it does not surprise me, how can snappy guess that lib is the
lib-dir to be added to LD_LIBRARY_PATH?

Maybe this is because of cmake-removing the runtime-path (rpath) from
program?
 
> Do you still have the wrapper generated by snapcraft in your snap/
> directory?

I unfortunately don't have access to it right now. But Yann should be
able to fetch it.

Thanks for your help.
--
Patrick.