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
