[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: transitive shared library dependencies and installation

From: Richard Purdie
Subject: Re: transitive shared library dependencies and installation
Date: Fri, 03 Jan 2020 15:02:08 +0000
User-agent: Evolution 3.34.1-2

On Thu, 2020-01-02 at 16:24 -0600, Bob Friesenhahn wrote:
> 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.

I think the challenge that libtool has here is that many of these older
systems that libtool supports aren't so prevalent anymore.

I work on the Yocto Project where we do a ton of cross compiling and
have to work with libtool but its mostly Linux with a small amount of
mingw/baremetal/darwin bits.

We have a number of libtool patches to sort cross compile issues which
really need discussion with upstream libtool. With the lack of
releases, our incentive to do that diminishes :(.

By reducing everything to the lowest common denominator, it means
libtool struggles to take advantage of any new linker technology too.

Finding new maintainers with the amount of knowledge of weird older
systems needed is going to be a struggle which only gets worse over
time :(

I do worry about the future here as libtool is a key part of the
autotools fabric but its most likely to be wholesale replaced given how
things are trending.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]