Re: PATCH: PR/17311: Wrong libgcc_s.so.1 is used by lt-gij

[H. J. Lu]

On Thu, Sep 23, 2004 at 03:35:25PM -0700, H. J. Lu wrote:
> On Thu, Sep 23, 2004 at 02:46:14AM +0100, Gary V. Vaughan wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi H.J,
> > 
> > On 7 Sep 2004, at 21:11, H. J. Lu wrote:
> > >I don't understand why libtool
> > >has to put the install directory in RPATH for compile. Removing it
> > >shouldn't cause any problem since the install directory may not exist
> > >during compile before "make install"
> > >
> > >2004-09-07  H.J. Lu  <address@hidden>
> > >
> > >   PR libgcj/17311
> > >   * ltmain.sh: Don't use "$finalize_rpath" for compile.
> > 
> > Libtool builds the library for the installation location by default,
> > and should relink if you try to run the uninstalled library.  You can
> > change this behaviour by configuring with --disable-fast-install.  Does
> > that fix gcj vs. lib_gcc for you, or am I missing a deeper problem?
> 
> I don't know how to try it with libtool in gcc.
> 
> > 
> > Applying this would mean that a library would always need to be relinked
> > at installation doesn't it?  While that is often the case anyway, not 
> > all platforms require a relink at the moment since 
> > - --enable-fast-install is
> > the default.
> > 
> 
> If --enable-fast-install puts the installed directory in DT_RPATH for
> compile, it is a bug in libtool. For ELF, DT_RPATH will be searched
> first before any other directories. You never want to do that. You want
> the newly built shared libraries for compile instead of the old one,
> which may be incompatible with the newly built binaries.
> 

What should we do here? ltmain.sh in gcc is wrong and what the
--enable-fast-install option in libtool does is totally wrong for ELF.
Should I apply

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00663.html


H.J.