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

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

[Bruno Haible]

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

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

[Ludovic Courtès]

Hi,

Bruno Haible <bruno@clisp.org> skribis:

> $ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake

It’s a mistake to explicitly binutils and glibc: they are provided by
‘gcc-toolchain’ along with an ‘ld’ wrapper that takes care of adding
entries to the RUNPATH of binaries:

  https://guix.gnu.org/manual/en/html_node/Application-Setup.html#The-GCC-toolchain

‘binutils’ shadowed that wrapper.  I admit what you did looks perfectly
legit at first sight and the failure mode isn’t great.

The fix is to run:

  guix remove glibc binutils

Another way to do software development is with ‘guix environment’:

  https://guix.gnu.org/manual/en/html_node/Development.html

For example, if you want to hack on Gettext, run:

  guix environment gettext

That spawns a shell containing all the development tools and environment
variables to hack on gettext.

HTH!

Ludo’.

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

[Bruno Haible]

Hi Ludo,

> > $ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake
> 
> It’s a mistake to explicitly binutils and glibc: they are provided by
> ‘gcc-toolchain’ along with an ‘ld’ wrapper that takes care of adding
> entries to the RUNPATH of binaries:
> 
>   https://guix.gnu.org/manual/en/html_node/Application-Setup.html#The-GCC-toolchain
> 
> ‘binutils’ shadowed that wrapper.  I admit what you did looks perfectly
> legit at first sight and the failure mode isn’t great.
> 
> The fix is to run:
> 
>   guix remove glibc binutils

This does fix it, thank you.

The question "What packages do I need to do normal C development?" should
really be documented.

How about a doc section - at the beginning of the chapter
https://guix.gnu.org/manual/en/html_node/Development.html - that says:

  Packages needed for C development
  =================================

  For C development, you will typically need the packages
    make gcc-toolchain gdb

  Do NOT install glibc and binutils explicitly, as they would shadow
  the 'ld' wrapper that is necessary for proper operation of GCC.

Additionally, the documentation page
https://guix.gnu.org/manual/en/html_node/Application-Setup.html
starts with the sentence
  "When using Guix on top of GNU/Linux distribution other than Guix System ..."
but then the majority of the page applies to native Guix as well.
How about restructuring this documentation chapter into two pages:
  - one that explains things valid about Guix in general,
  - one that covers only the foreign-distro topics.

> Another way to do software development is with ‘guix environment’:
> 
>   https://guix.gnu.org/manual/en/html_node/Development.html
> 
> For example, if you want to hack on Gettext, run:
> 
>   guix environment gettext
> 
> That spawns a shell containing all the development tools and environment
> variables to hack on gettext.

Sounds very interesting. But for the moment, I use guix only as a
test platform.

Bruno

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

[zimoun]

Dear Bruno,

Thank you for your feedback.


On Mon, 4 May 2020 at 01:10, Bruno Haible <bruno@clisp.org> wrote:

> > Another way to do software development is with ‘guix environment’:
> >
> >   https://guix.gnu.org/manual/en/html_node/Development.html
> >
> > For example, if you want to hack on Gettext, run:
> >
> >   guix environment gettext
> >
> > That spawns a shell containing all the development tools and environment
> > variables to hack on gettext.
>
> Sounds very interesting. But for the moment, I use guix only as a
> test platform.

Note that Guix (as package manager) provides 3 nice features for
development as a test platform: manifest, profile and channel.

1. Manifests allow you to specify the packages you want to install.
For example, this command installs make, gcc-toolchain and gdb in the
default profile (~/.guix-profile).

   guix package -m /path/to/my/manifest.scm

--8<---------------cut here---------------start------------->8---
(specifications->manifest
 '("make" "gcc-toolchain" "gdb"))
--8<---------------cut here---------------end--------------->8---

And note that "version" or "outputs" (debug) can be specified.  Well,
manifest can be used with almost all the Guix commands. And manifests
compose: "-m m1.scm -m m2.scm".

https://guix.gnu.org/manual/devel/en/guix.html#profile_002dmanifest


2. Profiles allow different versions of the same tool without any
conflict.  For example, let consider you would like to develop using
GCC@9 for one project and GCC@8 for another; then:

  guix install gcc-toolchain@9 -p /path/to/my/gcc-9
  guix install gcc-toolchain@8 -p /path/to/my/gcc-8

Then, for example let prepend the environment variables defined by the
packages gcc-toolchain@9.

  eval `guix package --search-paths=prefix -p /path/to/gcc-9`
  which gcc

Note that profiles compose too (see --allow-collisions; warning).
Moreover, the regular packages used to develop need time to time to be
temporary extended; without being really "installed":

   guix environment -m /path/to/my/manifest-dev-9.scm --ad-hoc libfoo

And options like '--pure' or '--container' are very useful for
testing.  And when finished, 'libfoo' becomes a dead link in the store
(guix gc --list-dead) and so would be garbage collected if needed; the
command "guix environment" is very handy when testing and developing,
iMHO.


3. Channels allow to track the exact version of the tools.  For
example, the version used:

    guix describe -f channels > /path/to/my/channel.scm

Then weeks (or month) or on another machine, it is possible to
re-install the same packages, for example:

   guix pull -C /path/to/my/channel.scm
   guix package -m /path/to/my/manifest.scm -p /path/to/my/olds

Note that it is not necessary required to pull back at one specific
Guix version for re-installing packages of this very specific Guix
version.  It is possible to temporarily re-state another Guix version
without modifying the current one (see Inferior):

  guix time-machine -C /path/to/my/channel.scm \
      -- package -m /path/to/my/manifest.scm -p /path/to/my/olds

This is equivalent to the 2 commands above but without "updating" the
current Guix.


I do not know if it is useful.  Or if it helps to describe Guix as a
test platform.  The manual is hairy -- from my point of view -- and
because Guix re-frames good ol' concepts, it is not easy to find the
way.

Best regards,
simon

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

[zimoun]

Dear Ludo and Bruno,

On Mon, 4 May 2020 at 01:10, Bruno Haible <bruno@clisp.org> wrote:

> The question "What packages do I need to do normal C development?" should
> really be documented.
>
> How about a doc section - at the beginning of the chapter
> https://guix.gnu.org/manual/en/html_node/Development.html - that says:
>
>   Packages needed for C development
>   =================================
>
>   For C development, you will typically need the packages
>     make gcc-toolchain gdb
>
>   Do NOT install glibc and binutils explicitly, as they would shadow
>   the 'ld' wrapper that is necessary for proper operation of GCC.

Does it make sense to provide example/sample of manifests for
developing in the main languages?
And add advices in the manual? For example:

   guix package -m /etc/guix/minimal-opinionated-tools-for-C.scm
   guix package -m /etc/guix/minimal-opinionated-tools-for-Python.scm

Well, I do not know what the correct location for such "examples"
files. Folder /etc/? Other?
And with a better name than "minimal-opinionated-tools-for-".

WDYT?


All the best,
simon

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

[Ludovic Courtès]

Hi,

Bruno Haible <bruno@clisp.org> skribis:

> The question "What packages do I need to do normal C development?" should
> really be documented.
>
> How about a doc section - at the beginning of the chapter
> https://guix.gnu.org/manual/en/html_node/Development.html - that says:
>
>   Packages needed for C development
>   =================================
>
>   For C development, you will typically need the packages
>     make gcc-toolchain gdb
>
>   Do NOT install glibc and binutils explicitly, as they would shadow
>   the 'ld' wrapper that is necessary for proper operation of GCC.

Good idea, I did something along these lines:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1f14e25c1969a93908288cb302a572f3cbbaa478

> Additionally, the documentation page
> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
> starts with the sentence
>   "When using Guix on top of GNU/Linux distribution other than Guix System ..."
> but then the majority of the page applies to native Guix as well.
> How about restructuring this documentation chapter into two pages:
>   - one that explains things valid about Guix in general,
>   - one that covers only the foreign-distro topics.

The locale and nscd bits are foreign-distro-specific, but the for the
rest I agree that something needs to be done.

Thanks for your feedback!

Ludo’.

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

[zimoun]

Hi Ludo,

On Mon, 4 May 2020 at 11:32, Ludovic Courtès <ludo@gnu.org> wrote:

> >   Packages needed for C development
> >   =================================
> >
> >   For C development, you will typically need the packages
> >     make gcc-toolchain gdb
> >
> >   Do NOT install glibc and binutils explicitly, as they would shadow
> >   the 'ld' wrapper that is necessary for proper operation of GCC.
>
> Good idea, I did something along these lines:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1f14e25c1969a93908288cb302a572f3cbbaa478

Compiling Fortran leads to the same issue, if I understand correctly.
Is it not the reason of the addition of 'gfortran-toolchain'?
And I guess it should be the same issue for the other front-ends that
GCC supports (Ada, etc.), isn't it?

Well, is it not GCC related and not only C specific?

I mean, I seems better to me to remove "@subsection The GCC toolchain"
from "Application setup" and then to retitle the subsection "The GCC
toolchain" in "Development" instead of "Packages for C Development".
Keeping for now how it is worded and letting the GFortran use case as
an exercise for the reader. ;-)


All the best,
simon

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

[Ludovic Courtès]

Hello,

zimoun <zimon.toutoune@gmail.com> skribis:

> Compiling Fortran leads to the same issue, if I understand correctly.
> Is it not the reason of the addition of 'gfortran-toolchain'?
> And I guess it should be the same issue for the other front-ends that
> GCC supports (Ada, etc.), isn't it?
>
> Well, is it not GCC related and not only C specific?
>
> I mean, I seems better to me to remove "@subsection The GCC toolchain"
> from "Application setup" and then to retitle the subsection "The GCC
> toolchain" in "Development" instead of "Packages for C Development".
> Keeping for now how it is worded and letting the GFortran use case as
> an exercise for the reader. ;-)

True!  Do you want to send a patch?  :-)

Thanks,
Ludo’.

bug#41038: [PATCH] doc: Reword "The GCC toolchain".

[zimoun]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

Hi Ludo

On Mon, 4 May 2020 at 21:52, Ludovic Courtès <ludo@gnu.org> wrote:

> True!  Do you want to send a patch?  :-)

See attached.  Feel free to reword the commit message if it is not
compliant with the standard.


Cheers,
simon

[-- Attachment #2: 0001-doc-Reword-The-GCC-toolchain.patch --]
[-- Type: text/x-patch, Size: 3669 bytes --]

From cefffd56f8363b45f3593814ec296015906854b4 Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Wed, 6 May 2020 19:26:05 +0200
Subject: [PATCH] doc: Reword "The GCC toolchain".

Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478
as discussed in <https://bugs.gnu.org/41038>.

* doc/guix.texi (Packages for C Development): Rename to...
(The GCC toolchain): ...this. Add gfortran-toolchain.
(Invoking guix package): Add guix-search anchor.
(Application Setup)[The GCC toolchain]: Remove.
---
 doc/guix.texi | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index bc5ecbbcde..5b56ae757d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -228,6 +228,7 @@ Development
 
 * Invoking guix environment::   Setting up development environments.
 * Invoking guix pack::          Creating software bundles.
+* The GCC toolchain::           Working with languages supported by GCC.
 
 Programming Interface
 
@@ -1767,13 +1768,6 @@ want to avoid auto-loading the Emacs packages installed with Guix, you
 can do so by running Emacs with the @code{--no-site-file} option
 (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
 
-@subsection The GCC toolchain
-
-@c XXX: The contents of this section were moved under
-@c ``Development'', since it makes more sense there and is not specific
-@c foreign distros.  Remove it from here eventually?
-@xref{Packages for C Development}, for information on packages for C/C++
-development.
 
 @node Upgrading Guix
 @section Upgrading Guix
@@ -3039,6 +3033,7 @@ availability of packages:
 
 @item --search=@var{regexp}
 @itemx -s @var{regexp}
+@anchor{guix-search}
 @cindex searching for packages
 List the available packages whose name, synopsis, or description matches
 @var{regexp} (in a case-insensitive fashion), sorted by relevance.
@@ -4669,9 +4664,9 @@ pack} command allows you to create @dfn{application bundles} that can be
 easily distributed to users who do not run Guix.
 
 @menu
-* Invoking guix environment::   Setting up development environments.
-* Invoking guix pack::          Creating software bundles.
-* Packages for C Development::  Working with C code with Guix.
+* Invoking guix environment::  Setting up development environments.
+* Invoking guix pack::         Creating software bundles.
+* The GCC toolchain::          Working with languages supported by GCC.
 @end menu
 
 @node Invoking guix environment
@@ -5335,13 +5330,15 @@ In addition, @command{guix pack} supports all the common build options
 (@pxref{Common Build Options}) and all the package transformation
 options (@pxref{Package Transformation Options}).
 
-@node Packages for C Development
-@section Packages for C Development
+
+@node The GCC toolchain
+@section The GCC toolchain
 
 @cindex GCC
 @cindex ld-wrapper
 @cindex linker wrapper
 @cindex toolchain, for C development
+@cindex toolchain, for Fortran development
 
 If you need a complete toolchain for compiling and linking C or C++
 source code, use the @code{gcc-toolchain} package.  This package
@@ -5355,7 +5352,9 @@ invoke the actual linker with this new set of arguments.  You can instruct the
 wrapper to refuse to link against libraries not in the store by setting the
 @code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
 
-
+The package @code{gfortran-toolchain} provides a complete GCC toolchain
+for Fortran development.  For other languages, please use
+@command{guix search gcc toolchain} (see @pxref{guix-search,, Invoking guix package}).
 
 @c *********************************************************************
 @node Programming Interface
-- 
2.26.1

bug#41038: [PATCH] doc: Reword "The GCC toolchain".

[zimoun]

Hi Ludo,

Friendly ping to avoid the tiny patch falls in the cracks.

Thanks,
simon

bug#41038: [PATCH] doc: Reword "The GCC toolchain".

[Nicolas Goaziou]

Hello,

zimoun <zimon.toutoune@gmail.com> writes:

> See attached.  Feel free to reword the commit message if it is not
> compliant with the standard.

I have two minor comments about it.

> +The package @code{gfortran-toolchain} provides a complete GCC toolchain
> +for Fortran development.  For other languages, please use
> +@command{guix search gcc toolchain}

Nitpick: I know there is plenty of this in the manual, but I suggest to
use @samp{guix ...}, not @command{...}.

> (see @pxref{guix-search,, Invoking guix package}).

You need to remove the "see ":

  (@pxref{...})


Regards,

-- 
Nicolas Goaziou

bug#41038: [PATCH] doc: Reword "The GCC toolchain".

[zimoun]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

Hi Nicolas,

Thank you for the review.  Attached the updated patch.

On Fri, 15 May 2020 at 21:42, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> > +The package @code{gfortran-toolchain} provides a complete GCC toolchain
> > +for Fortran development.  For other languages, please use
> > +@command{guix search gcc toolchain}
>
> Nitpick: I know there is plenty of this in the manual, but I suggest to
> use @samp{guix ...}, not @command{...}.

I did not know the difference.  Thank you for the nitpick.



All the best,
simon

[-- Attachment #2: v2-0001-doc-Reword-The-GCC-toolchain.patch --]
[-- Type: text/x-patch, Size: 3666 bytes --]

From efbc579a8884235ac37833ea6ee6fa454110c080 Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Wed, 6 May 2020 19:26:05 +0200
Subject: [PATCH v2] doc: Reword "The GCC toolchain".

Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478
as discussed in <https://bugs.gnu.org/41038>.

* doc/guix.texi (Packages for C Development): Rename to...
(The GCC toolchain): ...this. Add gfortran-toolchain.
(Invoking guix package): Add guix-search anchor.
(Application Setup)[The GCC toolchain]: Remove.
---
 doc/guix.texi | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 90324ce291..22bf6bd224 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -228,6 +228,7 @@ Development
 
 * Invoking guix environment::   Setting up development environments.
 * Invoking guix pack::          Creating software bundles.
+* The GCC toolchain::           Working with languages supported by GCC.
 
 Programming Interface
 
@@ -1773,13 +1774,6 @@ want to avoid auto-loading the Emacs packages installed with Guix, you
 can do so by running Emacs with the @option{--no-site-file} option
 (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
 
-@subsection The GCC toolchain
-
-@c XXX: The contents of this section were moved under
-@c ``Development'', since it makes more sense there and is not specific
-@c foreign distros.  Remove it from here eventually?
-@xref{Packages for C Development}, for information on packages for C/C++
-development.
 
 @node Upgrading Guix
 @section Upgrading Guix
@@ -3045,6 +3039,7 @@ availability of packages:
 
 @item --search=@var{regexp}
 @itemx -s @var{regexp}
+@anchor{guix-search}
 @cindex searching for packages
 List the available packages whose name, synopsis, or description matches
 @var{regexp} (in a case-insensitive fashion), sorted by relevance.
@@ -4675,9 +4670,9 @@ pack} command allows you to create @dfn{application bundles} that can be
 easily distributed to users who do not run Guix.
 
 @menu
-* Invoking guix environment::   Setting up development environments.
-* Invoking guix pack::          Creating software bundles.
-* Packages for C Development::  Working with C code with Guix.
+* Invoking guix environment::  Setting up development environments.
+* Invoking guix pack::         Creating software bundles.
+* The GCC toolchain::          Working with languages supported by GCC.
 @end menu
 
 @node Invoking guix environment
@@ -5388,13 +5383,15 @@ In addition, @command{guix pack} supports all the common build options
 (@pxref{Common Build Options}) and all the package transformation
 options (@pxref{Package Transformation Options}).
 
-@node Packages for C Development
-@section Packages for C Development
+
+@node The GCC toolchain
+@section The GCC toolchain
 
 @cindex GCC
 @cindex ld-wrapper
 @cindex linker wrapper
 @cindex toolchain, for C development
+@cindex toolchain, for Fortran development
 
 If you need a complete toolchain for compiling and linking C or C++
 source code, use the @code{gcc-toolchain} package.  This package
@@ -5408,7 +5405,9 @@ invoke the actual linker with this new set of arguments.  You can instruct the
 wrapper to refuse to link against libraries not in the store by setting the
 @env{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
 
-
+The package @code{gfortran-toolchain} provides a complete GCC toolchain
+for Fortran development.  For other languages, please use
+@samp{guix search gcc toolchain} (@pxref{guix-search,, Invoking guix package}).
 
 @c *********************************************************************
 @node Programming Interface
-- 
2.26.1

bug#41038: [PATCH] doc: Reword "The GCC toolchain".

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> From efbc579a8884235ac37833ea6ee6fa454110c080 Mon Sep 17 00:00:00 2001
> From: zimoun <zimon.toutoune@gmail.com>
> Date: Wed, 6 May 2020 19:26:05 +0200
> Subject: [PATCH v2] doc: Reword "The GCC toolchain".
>
> Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478
> as discussed in <https://bugs.gnu.org/41038>.
>
> * doc/guix.texi (Packages for C Development): Rename to...
> (The GCC toolchain): ...this. Add gfortran-toolchain.
> (Invoking guix package): Add guix-search anchor.
> (Application Setup)[The GCC toolchain]: Remove.

Applied, thanks!

Ludo’.

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

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

Hi Bruno,

On Sun, 03 May 2020 01:55:00 +0200
Bruno Haible <bruno@clisp.org> wrote:

> $ 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

I remember being tripped up by this when I started using Guix.  It is annoying.

I wonder if it's possible to instruct gcc (or ld, I guess) to automatically
add rpath to where it found the respective library.  That's really what we
expect to happen in Guix.

Ugly workaround:

$ wget https://ftp.gnu.org/gnu/gettext/gettext-0.20.1.tar.gz
$ tar xfz gettext-0.20.1.tar.gz
$ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake
# or better: guix environment --pure --ad-hoc gcc-toolchain make coreutils binutils glibc gdb gettext m4 autoconf automake sed grep gawk
(env)$ cd gettext-0.20.1/libtextstyle/examples/color-hello
(env)$ ./autogen.sh
(env)$ export LDFLAGS=-Wl,-rpath=`echo $LIBRARY_PATH | sed -e 's;:; -Wl,-rpath=;g'` 
(env)$ ./configure
(env)$ make
exit
$ ./hello
Hello

But unfortunately, Makefiles are not standardized in how to add linker
flags--so it's not easy to find out how to do that in general.

The above does work for gettext.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I remember being tripped up by this when I started using Guix.  It is annoying.
>
> I wonder if it's possible to instruct gcc (or ld, I guess) to automatically
> add rpath to where it found the respective library.  That's really what we
> expect to happen in Guix.

See the comment at the top of ld-wrapper.in.  I tried hard to avoid
having a wrapper at all but came to the conclusion that this was the
best we could do (it’s already better than what Nixpkgs did/does, which
is to wrap the whole compiler).

Thanks,
Ludo’.

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

[Bruno Haible]

Ludovic Courtès wrote:
> I tried hard to avoid
> having a wrapper at all but came to the conclusion that this was the
> best we could do

Can something be done to avoid that installing the packages 'glibc' and
'binutils' shadows this wrapper?

Maybe moving the wrapper to a different package than it is now?

Or adding specific metainformation to some packages?

Bruno