[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

["Ralf dot Wildenhues at gmx dot de" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #17 from Ralf dot Wildenhues at gmx dot de  2006-02-07 05:48 -------
(In reply to comment #16)
> Please read the summary line: "Wrong libgcc_s.so.1 is used by lt-gij". Ld.so
> will search DT_RPATH first for any shared libraries.

Yes.  So all that is missing is a notion in libtool to tell it
  "this path is to be added to the list of *uninstalled* run paths"
which would be added to the relinked-for-execution executable (after all
other uninstalled paths) but not the unrelinked one and not either to any
uninstalled libraries (on ELF, of course).  You have to have that notion
anyway because otherwise there would be no way you could add the run path
to libgcc_s to libtool safely at all (i.e. without ending up in installed
files).

In comment #8 you said:
> I don't know how to do --disable-fast-install for gcc.

As for --disable-fast-install, it's not optimal either.  But libtool could
create all libraries/programs with the uninstalled run paths (also the ones
given by above new flag) and after that all other given ones.  `make install'
will surely have to relink all of those; but I don't see the necessity for
a shell wrapper in this case either (on system where
shlibpath_overrides_runpath=no).

All there is missing for decent libtool support for "libtool + non-libtool
libraries in one build tree" is a notion to pass uninstalled run paths and
uninstalled link editor paths (-L), AFAICS.

By the way, I don't see any reason why the installed run paths should not be
put after the uninstalled ones (into the relinked-upon-execution executable).
You have to assume anyway that incompatible libraries may be found in the
default runtime linker search path, so really they are not contributing much
to the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311