Re: Multiple -rpaths

[Jan Engelhardt]

Hi Ralf,

On Sunday 2008-11-02 21:56, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Sun, Nov 02, 2008 at 05:24:27PM CET:
>> 
>> I have two libraries in paths that are not searched by default (e.g. 
>> /opt/foo/lib). So I have this in my pkgconfig files:
>> 
>> foo.pc: Libs:        -L${libdir} -lfoo
>> bar.pc: Libs:        -L${libdir} -lbar
>> 
>> The linker will find -lfoo,-lbar and successfully create the output file 
>> -- which is an .la library --, but running `ldd` on it says 
>> "libfoo.so.0 => not found", and that seems fine to me, since no -rpath 
>> was given. So I try to add -rpath in the pkgconfig files:
>
>Bzzt.  Libtool's way to list additional run paths is not -rpath, but -R.
>Yes, incredibly smart, I know, but we can't change it now.  -rpath is to
>say "the library I'm creating is to be installed later in this
>directory".

Well that ("is to be installed here") is not the intention, but
something more like "make the runtime linker look here" -- at least
that is what GNU ld(1) tells me about -rpath.

>So use -R, with or without following space.  With multiple paths, use -R
>path1 -R path2.  But even better if you don't use it at all; you should
>never need it to link against libtool libraries (those where an .la file
>is present).

.la is actually not present. Just the .so.

>If you need to specify a way that is both portable to libtool and a
>GNU binutils ld-using compiler, then use -Wl,-rpath -Wl,$(libdir). 
>Of course that breaks for some (few) non-GCC compilers (because they
>don't understand -Wl), and many non-GNU linkers (because they use
>something other than -rpath, or don't allow multiple instances of
>-rpath but need one flag with colon-separated optarg, or so).

Is not that what libtool is supposed to cover up? Maybe not for every
make invocation à la `make LD=zzzld`, but perhaps determining the
type of ld at configure-time.


thanks,
Jan