Re: Makefile.in, LIBTOOL and shared/static builds.

[Bob Friesenhahn]

On Mon, 25 Jun 2018, address@hidden wrote:

> > I’m curious - it’s neat that slibtool exists, but if you need
> > functionality offered by libtool then why not just use libtool?
>
> Frankly libtool is 12,000+ line shell script which is hard to
> understand, maintain, fix and is rather slow.

Agreed.

> A while ago with my 6 core AMD FX-6350 cpu I tested building
> libtomcrypt with both libtool and slibtool using six make jobs. This
> program does heavily use libtool, but does not use autotools.

[ results stuff removed ]

The overhead attributed to libtool seems rather high.  Is there 
something about your execution environment or your libtool usage which 
causes more overhead than usual?

> Here with a simple hello world I am seeing 1682 system calls with
> libtool and 345 with slibtool.

Agreed.  A shell script will always use more system calls and 
overhead than a simple utility since shell scripts are comprised of 
many calls to simple (or complex) utilities.

> One example I recall is where I found a configure.ac which was
> incorrectly using sed on the output of some internal commands and
> feeding the compiler bogus flags. Libtool silently swallowed the bug
> and moved on where slibtool helpfully printed the error, allowed the
> bug to be found and then fixed.

How does slibtool validate arguments?  Does it understand the specific 
set of arguments allowed by the compiler/linker being used?

> Additional benefits are that installing the .la files is optional (Most
> programs will not break if they are missing) and that there is only one
> slibtool binary for all the supported targets and target flavors.

What are the supported targets and target flavors?

Does slibtool discard most of the portabilty (host OSs and toolchains) 
offered by the libtool script?

> My understanding is the problem here is that slibtool works at a lower
> level than libtool and as a result is not able to rely on what is not
> in files like Makefile.in as libtool can. This should be relatively
> easy to fix in automake (?) with making it possible to obtain this
> information easier.

Usually it is possible to substitute Makefile text to replace the 
default rules used by Automake.  This should allow changing how 
Automake invokes the tool in order to pass additional arguments.  Have 
you tried that?

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