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 PATH Set 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
