Re: Problematic linking between glibc and shared libgcc

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb 21, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

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

Yes.  This used to be a problem.  This was certainly with an old
version of libtool, before it started creating different binaries for
installation and for in-build-tree-execution on systems whose
LD_LIBRARY_PATHs don't override RPATHs.

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

For an installed GCC, this can never be a problem.  I agree this is
going to be a problem in case of shared libraries or executables for
the target linked with the shared libgcc.  The only reasonable
approaches are to rely on LD_LIBRARY_PATH or equivalent to avoid
hardcoding the build-tree pathname into libraries or executables, or
link two different copies of shared libraries and programs, one for
installation and one for in-build-tree use.  libtool would take care
of these minor details, but we'd have to do it ourselves since libgcc
isn't a libtool library.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me