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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
