Re: BUG: library type search order

[Scott James Remnant]

On Wed, 2004-03-24 at 11:38, Gary V.Vaughan wrote:

> On 24 Mar 2004, at 02:08, Scott James Remnant wrote:
> > I've also decided that the lack of an rpath is actually right for
> > non-libtool libraries, we should only hardcode paths of libtool
> > libraries because we have more control over those.
> 
> Hmmm... I'm not so sure.
> 
> Read this thread and see if you change your mind :-)
> 
> http://lists.debian.org/debian-devel/1999/debian-devel-199902/
> msg00033.html
> 
Oh, I agree with RPATHing in general; I'm just not sure that we have all
the information when linking to a non-Libtool library:

        $ libtool --mode=link gcc -o test test.lo \
                -L/somewhere/lib -lfoo

If /somewhere/lib/libfoo.la exists, we actually have enough information
to encode the RPATH -- the .la file contains the actual libdir
(/somewhere might be a DESTDIResque prefix) and we can make a decision
about whether the RPATH is needed, and whether relinking is required
later.

When /somewhere/lib/libfoo.so is not a Libtool library, we don't really
have enough information.  We don't know whether there's a prefixed path
on the front so we can't determine the correct RPATH to encode or
relink.  Applying an RPATH here ourselves could break more than it
fixes, instead we should leave things up to the linker.

Also if people are linking against a non-Libtool library, and really do
want an RPATH, they can always specify -R:

        $ libtool --mode=link gcc -o test test.lo \
                -L/somewhere/lib -R/somewhere/lib -lfoo

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

signature.asc
Description: This is a digitally signed message part