On Thu, 2 Jan 2020, wf...@niif.hu wrote:
True, but man ld states in the -rpath-link option description that the
directories specified by -rpath options are used with a very high
priority for locating required shared libraries.
This is interesting but I am not seeing any use of -rpath-link in
libtool.
Neither do I, but I think it would be a possible way out of this
situation. I wonder what the reason could be for libtool not using it.
Libtool is a portability tool. If it were to depend on non-portable
features, then software would be implemented using it which is
non-portable and the software developers might not be aware of it.
If Libtool were to require GNU Linux, or GNU ld, or GNU gcc. or GNU
libc, or ELF, then it could not longer be described as a portability
tool.
Indeed, if one makes some assumptions and is willing to lose some
portability then it is not difficult to use underlying tools directly,
without using libtool at all.
At one time it was assumed that GNU software would reach the largest
number of potential users by being implemented in a portable fashion.
An alternative would have been to require that GNU software can only
be compiled on GNU systems (this would have been impossible to start
with since such a system did not exist) using GNU tools.
It's rather hard to get support for libtool, but I sorely need some,
because this issue hurts a real software project. Since this is the
first time I seriously deal with libtool, I certainly miss most of the
picture, so I sincerely appreciate your "piping up". Let's hope others
will join with time with their insights.
As far as I am aware, libtool is currently "between maintainers" and
needs fresh volunteers to become a libtool maintainer.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt