Missing LD_LIBRARY_PATH in (container) environment

  • Done
  • quality assurance status badge
Details
3 participants
  • Thompson, David
  • Ludovic Courtès
  • Roel Janssen
Owner
unassigned
Submitted by
Roel Janssen
Severity
normal
R
R
Roel Janssen wrote on 30 Nov 2016 13:58
(address . bug-guix@gnu.org)
rbuoa0xxgyg.fsf@gnu.org
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.

Thanks.

Kind regards,
Roel Janssen
T
T
Thompson, David wrote on 30 Nov 2016 15:14
(name . Roel Janssen)(address . roel@gnu.org)(address . 25072@debbugs.gnu.org)
CAJ=RwfZ=tAfvST22+Omuw0ib47Y7cyAvh1QOCSSiu7SKOQtdsQ@mail.gmail.com
On Wed, Nov 30, 2016 at 7:58 AM, Roel Janssen <roel@gnu.org> wrote:
Toggle quote (32 lines)
> 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
L
L
Ludovic Courtès wrote on 1 Dec 2016 15:15
control message for bug #25072
(address . control@debbugs.gnu.org)
874m2nspl6.fsf@gnu.org
tags 25072 notabug
close 25072
?