libtool
[Top][All Lists]
Advanced

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

Re: Fwd: curious...


From: Ralf Wildenhues
Subject: Re: Fwd: curious...
Date: Sat, 21 Oct 2006 13:31:06 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Kyle,

* Kyle Sallee wrote on Sat, Oct 21, 2006 at 12:48:24AM CEST:
> There was a signifigant delay between when
> I sent a request to join the list and the confirmation email.

I think there was a server outage sometime in the last couple of days.
I've discarded your earlier, pending message now.

> I was looking at a 26M sh -x trace of an invocation of libtool
> while compiling koffice to see why so many CPU cycles were
> being spent on running the libtool shell script.

Please post the link command line that caused this.  If you have web
space, put up the --debug log somewhere, bzip2'ed.  Post the URL of the
package (or how to get it).  How long did the script take?

> Is it out of the question to keep lists separated by line feeds
> instead of spaces and then use the sort and uniq instead
> of case statements?

You cannot reorder the arguments in general.  $libs: No go.
That $special_deplibs may be reordered (at least I *think*
they may) is a rather subtle point.

> There are also some parts that look obviously slow...

Possibly moving a test from inside to outside may help things.
But have you measured that it helps?  Let's avoid optimization
that isn't relevant in practice (for at least some case), it's
not worth risking a regression.

> Does the use of backticks or $( subshells break portability of libtool?

Portability is explained quite well in the POSIX standard with most
additional restrictions described in the Shell Portability section
of the Autoconf 2.60 manual.  The list of allowed tools is in the GCS.

(Although there are some bits in ltmain of the form: "this comment was
added because otherwise shell xyz coredumps[1].)

> However, some modification could probably yield
> several magnitudes of execution speed increase.

I posted some patches last year on the libtool-patches list (one issue
of which has since been applied) that would reduce complexity for
linking libjava.  They were not concerned with a large number of deplibs
though, rather a large number of objects.
http://lists.gnu.org/archive/html/libtool-patches/2005-05/msg00153.html

The ensuing discussion helps to show some obstackles.

> Would you like me to hack a little on libtool just to
> increase it's execution speed or are such changes
> trivial to accomplish now that I mentioned it?

Foremost we would like to release 2.0 eventually, and thus avoid any
destabilizing of the code.  Other than that, we welcome contributions,
of course.

Cheers,
Ralf

[1] speaking of which: some ksh variants dump core with CVS HEAD libtool
currently, but only in some occasions.  :-/




reply via email to

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