[[former maintainers removed from Cc:]] Hi Filipe,
> On Aug 26, 2014, at 5:17 AM, Filipe Brandenburger <filbran...@google.com> > 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 > <filbran...@google.com> 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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool