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
bfrie...@simple.dallas.tx.us 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
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
On Tue, 2 Dec 2014, Filipe Brandenburger wrote: 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. This solves the problem (automatic addition of -rpath) caused by libtool on GNU/Linux. It is not truely portable since it can not solve automatic tool behavior on other operating systems. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
[[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
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
On Fri, 28 Nov 2014, Gary V. Vaughan wrote: 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. I am not sure what OS is being discussed here since it was never mentioned. 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). Some systems hard code the linker run-time path and this may be necessary in order for libtool to support executing built uninstalled binaries for testing. That is why libtool supports a 'finish' mode so make sure that finally installed executables contain the correct embedded path information. I don't think that linking against libraries in DESTDIR is portable. DESTDIR should be considered an install/copy-only option to support packaging. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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
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
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
Hi Filipe, 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. [SNIP] 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.) Libtool exclude directories from RPATH if path is listed in sys_lib_dlsearch_path_spec - list of space separated directories. Variable sys_lib_dlsearch_path_spec is generated from a libtool macro. On linux with FSF libtool version value start with /lib /usr/lib and existing directories from /etc/ld.so.conf . After configuration user could check current value with command: $ ./libtool --config | grep sys_lib_dlsearch_path_spec ( I assume that package build process generate libtool script in build directory ) You could use lt_cv_sys_lib_dlsearch_path_spec to override it at configure time. .../configure \ ... lt_cv_sys_lib_dlsearch_path_spec=ORIGINAL VALUE STAGING_PATH ... Regards Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool
