This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Problematic linking between glibc and shared libgcc
Alexandre Oliva <aoliva@redhat.com> writes:
> As a data point, libtool has always hard-coded library installation
> directories in executables, and the only time this was disputed was
> because of a misunderstanding about the consequences. Someone thought
> s/he'd be unable to move executables and libraries because of such
> hard-coding. Since this can be done, given the reasonable conditions
> I posted in my previous message, I think it wouldn't be a problem if
> GCC did it too.
My experience of libtool doing this was with BFD. After about the
third time I tried to fix a bug, recompiled, and saw that the bug was
not fixed, I realized that my recompilations were useless because the
bug was being fixed in the libbfd.so in the build tree but was still
present in the installed libbfd.so, and the RPATH was overriding all
my efforts to get ld.so to use the libbfd.so in the build tree.
This demonstrates a whole class of problem, which is executables which
have RPATH entries that point to a valid library that is not the one
that will work. The user can't do anything about this if they can't
(for whatever reason) move the library or change the executable.
It was very shortly after that I wrote a utility to remove RPATH
entries from executables.
--
- Geoffrey Keating <geoffk@geoffk.org>