Trying to get libtool not to add -rpath, since libs are only in a staging directory
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
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
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... 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? Cheers, Filipe On Tue, Aug 19, 2014 at 4:33 PM, Filipe Brandenburger 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
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
Hi Gary, Bob, Thanks for your feedback! In the end, I found Roumen Petrov replied to the list indicating that setting lt_cv_sys_lib_dlsearch_path_spec when calling configure might be able to solve this and indeed it did. http://lists.gnu.org/archive/html/libtool/2014-08/msg4.html By passing lt_cv_sys_lib_dlsearch_path_spec="${stagedir}/usr/lib" (I'm not linking to anything under the system's /usr/lib so it's OK for me to omit it) I managed to get it not to add that directory to the rpath. I wish that this "sys_lib_dlsearch_path_spec" variable was better documented in libtool's documentation... I'd be happy to try to contribute but unfortunately I don't think I understand them well enough to give them a good description... Let me know if you think I could help with it anyhow. Replying to some of your comments: On Fri, Nov 28, 2014 at 10:37 AM, Bob Friesenhahn wrote: > I am not sure what OS is being discussed here since it was never mentioned. This is on GNU/Linux and I'm using either the GNU ld and the gold linker (ideally I want both to work.) Both seem to support -rpath and -rpath-link but that doesn't seem to be part of the problem (as just adding the directory to lt_cv_sys_lib_dlsearch_path_spec was enough to solve it.) > GNU ld on GNU/Linux has these options: > > -rpath PATH Set runtime shared library search path > -rpath-link PATHSet link time shared library search path > > Notice that one is the path used for the installed library and the other is > for linking. It is more correct to use -rpath-link for libraries which are > not in their final resting place. However, the libraries do remember the > -rpath-link option which was used when they were linked, and libraries > linked with them inherit the option (to support cascading linkage). So in my actual case I'm installing libraries to a ${GNU_PLATFORM} subdirectory of /usr/lib where ${GNU_PLATFORM} is set to the GNU triplet. So, I'm actually passing ./configure both the lt_cv_sys_lib_dlsearch_path_spec="${stagedir}/usr/lib/${GNU_PLATFORM}" variable and also LDFLAGS="-Wl,-rpath,/usr/lib/${GNU_PLATFORM} -Wl,-rpath-link,${stagedir}/usr/lib/${GNU_PLATFORM}" which gets it to *add* the -rpath I want and to link to the libraries in the correct location. > I don't think that linking against libraries in DESTDIR is portable. DESTDIR > should be considered an install/copy-only option to support packaging. Well, in my use case I'm often/usually cross compiling so having the final libraries installed under /usr/lib is not really an option... It seems that lt_cv_sys_lib_dlsearch_path_spec solved the issue for me, but I'm not 100% positive how portable that is, if you can think of some reasons why this is not a good fix and if there's a cleaner way to accomplish this then please let me know. Cheers, Filipe ___ https://lists.gnu.org/mailman/listinfo/libtool