bug#25072: Missing LD_LIBRARY_PATH in (container) environment

["Thompson, David" <dthompson2@worcester.edu>]

On Wed, Nov 30, 2016 at 7:58 AM, Roel Janssen <roel@gnu.org> wrote:
> Dear Guix,
>
> When I create a separate environment using:
>
> $ guix environment --container --pure --ad-hoc --network autoconf \
>     automake make libtool pkg-config postgresql valgrind sed coreutils \
>     binutils gcc glibc grep sed glib gawk findutils bash
>
> Then compile my program:
> $ make
> ...
>   CCLD     myprogram
>
>
> Then try to run it:
> $ ./myprogram
>
> It fails with:
> ./myprogram: error while loading shared libraries: libglib-2.0.so.0: \
> cannot open shared object file: No such file or directory
>
> So, it cannot find glib while I had included it in the list of packages
> to make available in the container.
>
> When I set LD_LIBRARY_PATH as:
> export LD_LIBRARY_PATH=$LIBRARY_PATH
>
> The program runs fine.
>
> Therefore, I believe we should set LD_LIBRARY_PATH as well in the
> container.

No, this is undesirable.  Using LD_LIBRARY_PATH is not good practice
because it is just hacking around the real issue: The application was
not compiled correctly.  The solution to your problem is to use the
gcc-toolchain package instead of including binutils, gcc, glibc, etc.
manually.  gcc-toolchain will do the right thing.

Hope this helps,

- Dave