Re: transitive shared library dependencies and installation

[wferi]

Bob Friesenhahn <address@hidden> writes:

> On Thu, 2 Jan 2020, address@hidden 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.
>
> 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?

> As far as I am aware, libtool is currently "between maintainers" and
> needs fresh volunteers to become a libtool maintainer.

Fresh volunteers with arcane knowledge... quite a tall order! :)

Back to my problem: first I'd like to establish whether the behavior I
see is a bug, and if it is, is it in Libtool or in my code or somewhere
else.  And then find a solution or at least a workaround.  Opinions?
-- 
Thanks,
Feri