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

Debbugs page

R
R
Roel Janssen wrote on 30 Nov 2016 04: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 06: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 06:15
control message for bug #25072
(address . control@debbugs.gnu.org)
874m2nspl6.fsf@gnu.org
tags 25072 notabug
close 25072
?
Your comment

This issue is archived.

To comment on this conversation send an email to 25072@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 25072
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch