libtool
[Top][All Lists]
Advanced

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

Re: TODO


From: Ralf Wildenhues
Subject: Re: TODO
Date: Tue, 16 Nov 2004 07:50:38 +0100
User-agent: Mutt/1.4.1i

* Howard Chu wrote on Mon, Nov 15, 2004 at 10:29:04PM CET:
> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
> 
> >>Also, what do we do about -rpath?  We still need to encode the
> >>runtime path to even the dropped deplib directories so that the
> >>same library we linked with is picked up at runtime.
> 
> >Erm, is this not handled in the depending library? (I have no idea,
> >really, but I hoped this would be so.)
> 
> This is definitely a sticky problem. We do builds that "install" to a 
> path that is different from their actual, final destination. I'm finding 
> that the rpath handling at various stages of a build tries to be too 
> smart for its own good. E.g., I have a build tree in my home directory 
> for a number of packages in ~/BLD, the ultimate destination is /opt/foo, 
> and everything is staged into ~/BLD/opt/foo. For files in the resulting 
> package that contain embedded RPATH/RUNPATHs, I only want "/opt/foo" 
> present in the binary, but I find a lot of instances of 
> "/home/hyc/BLD/opt/foo" that I have to squash by manually relinking.

This sounds to me like a genuine bug in Libtool, *not* a structural
limitation that cannot be overcome.  Can you be bothered to provide a
testcase which exposes this failure?

Regards,
Ralf




reply via email to

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