bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: H. J. Lu
Subject: Re: PATCH: PR/17311: Wrong libgcc_s.so.1 is used by lt-gij
Date: Thu, 23 Sep 2004 15:35:25 -0700
User-agent: Mutt/1.4.1i

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.



H.J.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]