libtool
[Top][All Lists]
Advanced

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

Re: Found process taking too much CPU: libtool


From: Ralf Wildenhues
Subject: Re: Found process taking too much CPU: libtool
Date: Mon, 27 Nov 2006 07:16:20 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Brad,

* Brad Allen wrote on Mon, Nov 27, 2006 at 05:59:09AM CET:
> Bob Friesenhahn:
> " On Fri, 24 Nov 2006 address@hidden wrote:
> " > My system has slowed to a dog lately, and I found the culprit:
> " > libtool.
> " 
> " What version of libtool is being used?
> 
> Is libtool packaged with each package?

Typically, yes.  It isn't always trivial (and it helps much to have all
of Autoconf, Automake, and Libtool installed below the same prefix).

> Then the version is dependent
> upon whatever is most recently used with each package.  I checked the
> libtool site after posting this and realized libtool is not changing
> much lately, so hopefully it doesn't matter.

There hasn't been a release from the HEAD branch in a looong time.
Yes, we need to find some time to finish it up.  You can grab a nightly
tarball.

> $ libtool --version
> ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

No, that's branch-1-5.

You can usually get at least some speedup by using a fast shell.
Configure with
  CONFIG_SHELL=/bin/ash /bin/ash ../configure CONFIG_SHELL=/bin/ash

(not sure if ash is the best choice).

> Can it be used for existing builds or do I have to hand-integrate it
> for each build?

Usually, you have to hand-integrate for each build.  In many cases you
can try to just
  make LIBTOOL=/my/overridden/libtool

(with GNU make).

> I was thinking of the best ways to improve libtool speed.

Maybe I should post the patch splitting the libtool script in two (the
link mode, and the rest).  It saves about 20% time against the HEAD
version; so that much would appear to just be script parsing overhead.

> Besides
> converting it all to C (especially since gcc is so much faster now), a
> "jit" compiler for shell script might have been a good idea if it were
> not for the fact that shell scripts use expensive external programs
> for extremely trivial operations

Sure.  If you point out external programs in the compile mode part of
libtool that can be replaced portably, then by all means please point
them out.  (If you're not proficient with shell portability, then go
read the Autoconf manual about this first.)  I assume that link mode
isn't the biggest problem as it's invoked much less often, so it's ok
if that is slower for now.

You may be interested that Robert Ă–gren wrote a package called
libtool-cache (search the archives of libtool and libtool-patches
lists).  It may or may not help you.

Cheers,
Ralf




reply via email to

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