Bob Friesenhahn <[email protected]> writes:
> On Thu, 2 Jan 2020, [email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.