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

[Bruno Haible <bruno@clisp.org>]

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