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

[address@hidden]

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

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.

With libtool:

real    0m43.242s
user    2m9.735s
sys     0m38.435s

With slibtool:

real    0m12.180s
user    0m42.789s
sys     0m10.406s

Another way to represent the performance difference is by compiling a
single file and measuring the system calls with 'strace -fc'.

libtool --mode=compile --tag=CC /bin/true -c foo.c

or

slibtool --mode=compile --tag=CC /bin/true -c foo.c

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

==================
$ cat /tmp/hello.c 
#include <stdio.h>
int main()
{
   // printf() displays the string inside quotation
   printf("Hello, World!");
   return 0;
}
==================

These performance boosts can make a significant difference with
projects like mesa which are updated often. The smaller and actively
maintained code base is also encouraging, but another thing I would
like to point out is that one of libtool's "features" is that it will
ignore bugs from various configure.ac or Makefile.am files and will
successfully build a program with potentially unintended behavior.

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.

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.

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.

Alternative suggestions on how to improve this would be of course
welcome.

Note that this may of been sent twice, I'm not sure if the first e-mail
was correctly sent...