bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41038: gcc creates binaries that don't find their shared libraries


From: Bruno Haible
Subject: bug#41038: gcc creates binaries that don't find their shared libraries
Date: Sun, 03 May 2020 01:55:00 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; )

Hi,

I'm using the recent guix-system-vm-image-1.1.0.x86_64-linux.

After installing a couple of package for development
$ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf 
automake
I expected to be able to build GNU bison 3.5.91 from source. But I hit a build
failure, due to a program being linked against a shared library that cannot be
found.

How to reproduce (simple test case):
----------------
$ wget https://ftp.gnu.org/gnu/gettext/gettext-0.20.1.tar.gz
$ tar xfz gettext-0.20.1.tar.gz
$ cd gettext-0.20.1/libtextstyle/examples/color-hello
$ ./autogen.sh
$ ./configure
...
checking how to link with libtextstyle... -ltextstyle
...
$ make
...
gcc -g -O2 -o hello hello.o -ltextstyle
$ ./hello
./hello: error while loading shared libraries: libtextstyle.so.0: cannot open 
shared object file: No such file or directory
$ ldd hello
...
        libtextstyle.so.0 => not found
...


Discussion
----------

For packages *installed by the user*, the configure test has
code to add -Wl,-rpath,DIR options for appropriate directories.

However, here, the library has been installed by the system (through
'guix install gettext'). It appears that gcc, when searching for the
library, finds it. Whereas the dynamic loader (ld-linux-x86-64.so.2)
apparently does not find it.

It should be GCC's job to create binaries that work, when all
referenced libraries are system libraries. The ELF file format and
dynamic loader have enough facilities to make this possible (-Wl,-rpath
option, ld.so.conf, ld.so.cache).


Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]