Re: transitive shared library dependencies and installation

[Bob Friesenhahn]

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