Re: transitive shared library dependencies and installation
Bob Friesenhahn <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.general |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2 Jan 2020, [email protected] 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 [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt