|
From: | Bob Friesenhahn |
Subject: | Re: transitive shared library dependencies and installation |
Date: | Thu, 2 Jan 2020 16:24:59 -0600 (CST) |
User-agent: | Alpine 2.20 (GSO 67 2015-01-07) |
On Thu, 2 Jan 2020, address@hidden wrote:
If Libtool were to depend on non-portable features, [...] then it could not longer be described as a portability tool.In my understanding, Libtool is a portability shim, providing a regular interface for developers across systems with wildly varying features. It already uses non-portable features, just different ones on different architectures. I don't say it should use -rpath-link generally, I only suggested that it might be an efficient solution on systems supporting it. But I expect all systems supporting shared objects to allow using and installing them some way, irrespective of their interdependencies. Am I overly naive?
Certainly, libtool could use -rpath-link where it is supported but libtool provides a common feature set and if it is only possible to support a feature where -rpath-link is available, then offering the feature would defeat the purpose of being a portability tool.
Sometimes it is better to force the using software to conform to the limitations.
Libtool must also work for static linking. It seems to me that your issue also impacts static linking.
Bob -- Bob Friesenhahn address@hidden, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
[Prev in Thread] | Current Thread | [Next in Thread] |