Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Gary V. Vaughan]

[[former maintainers removed from Cc:]]

Hi Filipe,

> On Aug 26, 2014, at 5:17 AM, Filipe Brandenburger <address@hidden> wrote:
> 
> Friendly ping?
> 
> +cc the libtool maintainers according to http://www.gnu.org/software/libtool/
> 
> If this is indeed a bug, I'd be willing to invest some time in trying
> to fix it, but I'd need some pointers on what would be the proper way
> to fix it...

Currently, I believe libtool uses the presence of -rpath to determine
whether it should try to link a shared archive (at least in my very
cursory testing, I only get static archives if I miss the -rpath argument).

Also, the use of -rpath is fairly deeply ingrained into the way that
automake generated rules call libtool, so if you want to tackle a complete
patch, there will be at least some work there too.

I suspect that there is a fairly good chance that the -rpath requirement came
about because some supported architectures refuse to build shared libraries
without it, but I have access to only a tiny fraction of the architectures that
libtool supports so I can't test my hypothesis.

All of that said, I do agree that it is a bug for libtool not to respect
the value of $DESTDIR when it assembles the rpath directories.  I would think
a patch should be relatively straight forward though - find the parts of
ltmain.in that assemble the link line with the rpath directories, and strip
out any $DESTDIR prefixes from those paths before handing off to the linker.

> I really think libtool should be creating a wrapper script and not a
> binary with an rpath pointing to the stage directory, am I wrong?

No, I agree with you.

And I'd be happy to help you massage a suitable patch into something I can
apply to the repository.

> Cheers,
> Filipe

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

> On Tue, Aug 19, 2014 at 4:33 PM, Filipe Brandenburger
> <address@hidden> wrote:
>> Hi,
>> 
>> I'm trying to link binaries to libraries that are not installed on the
>> system, but just unpacked to a "staging" directory.
>> 
>> Consider this (real) example:
>> 
>> 1) Build expat with "--libdir=/usr/lib/${platform}"
>> 2) Install expat with "make install DESTDIR=${stagedir}"
>> 3) Configure dbus with "-L${stagedir}/usr/lib/${platform}" where it
>> will find expat now, and "-rpath /usr/lib/${platform}" where it will
>> find expat at real runtime when both are installed.
>> 4) Build expat
>> 
>> The problem is that ${stagedir} is leaking and the resulting
>> dbus-daemon gets both /usr/lib/${platform} and
>> ${stagedir}/usr/lib/${platform} added to it...
>> 
>> I tried working around it by passing --with-sysroot=${stagedir} to the
>> dbus configure, but unfortunately that didn't work...
>> 
>> Do you have a suggestion of something I could do to accomplish what
>> I'm trying to accomplish?
>> 
>> Is this a libtool bug?
>> 
>> Any suggestions of workarounds?
>> 
>> (I also filed a bug at
>> http://savannah.gnu.org/support/index.php?108637 in case this is
>> actually a libtool bug.)
>> 
>> Thanks in advance!
>> Filipe