[Top][All Lists]

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

Re: BUG: library type search order

From: Scott James Remnant
Subject: Re: BUG: library type search order
Date: Wed, 24 Mar 2004 14:01:29 +0000

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

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

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

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

reply via email to

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