Re: Several questions about libtool

[Bob Friesenhahn]

On Sat, 7 Jan 2012, Russ Allbery wrote:
> I wouldn't argue for breaking Libtool's ability to handle such platforms,
> or for that matter old UNIX platforms that don't support transitive
> resolution of shared library dependencies.  But I think Libtool needs some
> mechanism to correctly support platforms where adding spurious NEEDED ELF
> metadata is wrong and causes serious issues for distributions.  The
> pkg-config approach seems to work reasonably well in practice.

I think that it is wrong to solely blame libtool for this state of 
affairs.  In order for a project to work properly on non-ELF systems, 
or where installed shared libraries have abbreviated/truncated ELF 
implicit dependencies, or where static libraries are involved, the 
project needs to add all dependencies to LIBS during the configure 
run.  This is well before libtool is even involved.  If configure 
scripts do not do this, then linker errors (due to missing libraries) 
will block tests for symbols and library features.

Because of the need to extend LIBS in configure, and because of the 
desire to support more systems than just GNU/Linux (or ELF-based 
systems which behave similarly) many carefully-maintained projects are 
already requesting/applying far more libraries than would be necessary 
to link the application/library under GNU/Linux.  My own project is a 
good example of this.

The library-dependency problems are more complex than they have been 
made out to be since they are due to responsible-project behavior and 
not only due to excessively-pedantic libtool behavior.

I do agree that a tool can help solve these issues.  The linker itself 
is in the best position to know which library dependencies are really 
needed and to skip those which are not.

Libltdl's automatic loading of dependency libraries based on the 
content of .la files is a secondary issue to be addressed.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/