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 <[EMAIL PROTECTED]> > > > > > > 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. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool