Subject: Re: libtool problem with runtime shlib path propagation
To: Todd Vierling , Nick Hudson <skrll@netbsd.org>
From: Nick Hudson <skrll@netbsd.org>
List: tech-toolchain
Date: 02/15/2002 15:46:41
On Friday 15 February 2002 3:26 pm, Todd Vierling wrote:
> On Fri, 15 Feb 2002, Nick Hudson wrote:

[description of libtool -rpath deleted]

> : This bit is right.
> :
> : > The option to libtool's -rpath will not appear in the DT_RPATH of the
> : > resulting library.
> :
> : ...but this bit is apparently wrong. The option to -rpath does appear in 
> : the DT_RPATH. That seem's wrong to me... just because libfoo.la gets 
> : installed into a directory doesn't mean any of it dependencies are there.
> 
> Yah, I see what you mean now.  Looking at libtool's doc, I'm going to do a
> 180 here and say that the appropriate flag *is* -Wl,-R${X11BASE}....

The problem with -Wl, is that nothing gets put into the .la file which is 
what Matthias needs (I think).

Maybe libtool should be made to include the -Wl, stuff in the dependency_libs 
in the .la file.

> The reason I say this is that "-Wl," is interpreted by libtool itself, and
> reduced to -R.  For platforms on which "cc -shared" is appropriate, "cc"
> will accept "-R" as an argument.  For platforms where the linker is "ld
> -Bshareable", the -R option will be passed to "ld" directly, so it's still
> OK.

This description is not strictly correct. -Wl, gets interpretted by libtool 
into the equivalent compiler and linker options. When you use a compiler to 
link it should get the compiler options and if you use a linker to link it 
should get the linker options. So, I don't believe a compiler will ever see 
-R.

Nick

ps. this should come with the disclaimer that libtool is an enigma at the 
best of times and so it could all be wrong. :)