Bob Friesenhahn <bfrie...@simple.dallas.tx.us> writes: > On Thu, 2 Jan 2020, wf...@niif.hu 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
