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