[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:, LIBTOOL and shared/static builds.

From: Bob Friesenhahn
Subject: Re:, LIBTOOL and shared/static builds.
Date: Mon, 25 Jun 2018 13:46:58 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

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.


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 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 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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]