* bug#25072: Missing LD_LIBRARY_PATH in (container) environment
@ 2016-11-30 12:58 Roel Janssen
2016-11-30 14:14 ` Thompson, David
0 siblings, 1 reply; 2+ messages in thread
From: Roel Janssen @ 2016-11-30 12:58 UTC (permalink / raw)
To: 25072
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#25072: Missing LD_LIBRARY_PATH in (container) environment
2016-11-30 12:58 bug#25072: Missing LD_LIBRARY_PATH in (container) environment Roel Janssen
@ 2016-11-30 14:14 ` Thompson, David
0 siblings, 0 replies; 2+ messages in thread
From: Thompson, David @ 2016-11-30 14:14 UTC (permalink / raw)
To: Roel Janssen; +Cc: 25072
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-11-30 14:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-30 12:58 bug#25072: Missing LD_LIBRARY_PATH in (container) environment Roel Janssen
2016-11-30 14:14 ` Thompson, David
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).