Re: Several questions about libtool

[Peter O'Gorman]

On 01/06/2012 11:21 AM, Stepan Kasal wrote:
> 1) .la file always contains the recursively evaluated list of libraries.
> While this is necessary for static linking and dumb dynamic linkers,
> it is an issue for dyn. linkers that can do recursive resolution
> (which is the case on GNU/Linux distributions for many years).
> (I believe that the rule that forbids packing .la files to -dev and
> -devel subpackages on Debian and Fedora (respectively), is there just
> to work around this problem.)

This is still an issue, libtool always adds all dependencies. Many 
packages assume this and don't explicitly add required dependencies to 
Makefile.am etc. I don't recall the arguments for not changing this when 
building shared. IIRC Scott tried to include Debian's patch at some 
point. I'll look it up in the archives later.

> 2) People told me libtool is slow and shell has to parse huge script
> just to find out that it has to call gcc twice, with and without
> -fPIC.  Again, this is not about the general portability case, it is
> a request for optimization on GNU/Linux platform, that they percepts
> as one of the major customers of libtool.

Libtool is faster than it used to be, the shell does have to parse quite 
a bit of script, but compile mode has been moved as close to the 
beginning of the script as possible to reduce that time, and the number 
of forks has been reduced drastically for modern shells. I believe dash 
and ksh93 are faster than bash at running libtool. Last time I checked, 
libtool's compile mode wasn't significantly slower than using dolt 
(http://dolt.freedesktop.org/).

> 3) Does it happen often in practice that a project builds both -fPIC
> and non-pic objects, even though only one of them is going to be
> used?  If yes, and if it is because of a mistake on package
> maintainer's side, can something be done about it?  (warnings, changed
> defaults, autodetection in automake)

Perhaps the default should be --enable-shared --disable-static? It's 
worth considering.

Peter