Re: transitive shared library dependencies and installation

[Bob Friesenhahn]

On Fri, 3 Jan 2020, Richard Purdie wrote:

> > 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.

This is true.  It is possible that support for some archaic compilers 
and systems should be removed since there is no way to verify that the 
support works anymore, and there might not be any more active users.

Regardless, libtool must continue to support static linking, even if 
deployment usually uses dynamic linking.  As a developer, I use static 
linkage for daily development yet recommend dynamic linkage for 
most deployments.

> 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 :(.

You can become part of upstream libtool and commit your fixes 
directly.

> 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 :(

Most systems are not so weird.  Most problems with legacy targets have 
been due to shell and common utility differences/bugs (e.g. depending 
on 'bash' syntax or behavior of 'echo'.  These problems are due to the 
Autotools assumption that Autotools should be able to work with the 
shell and utilities that originally came with the system.

If it is impossible to find a representative target system to test on, 
then that is an indication that support should be deprecated.  Users 
of unpopular systems need to stand up for themselves and assist, even 
if only by providing remote access to test on the system.

> 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.

The current trend is that all of Autotools at risk even though it 
still works pretty well.  Perhaps Automake is in best shape since it 
was released most recently.  Autoconf has continued to be developed, 
but has not been released.

Autoconf 2012
libtool 2014
Automake 2017

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