V3 Configury

Mark Mitchell mark@codesourcery.com
Mon Jan 22 21:03:00 GMT 2001


The V3 configury bits are agonizing slow on systems that aren't too
fast, have relatively slow shells, are multilibbed, and where gcc
takes a while to link a program.  (AIX seems to be one such system,
depdening on what vintage of CPU you have.)  David, what are all the
multilibs for?

Given that I started a bootstrap last night at 10PM and checked on it
at 8AM to find it still configuring V3 (admittedly, it took several
hours just to complete the bootsrap), this is pretty painful.

A lot of that time is going to checking for the existence of a billion
different math functions.  The problem is that we check for each
function individually -- first we check for acosf, then we check for
asinf, then we check for acosf, etc.  Each of these requires a full
link.  On systems using collect2, that requires an invocation of the
compiler (to build static destructors), too.  Bottom line: each of
these tests takes multiple seconds to run.

Some of these tests are redundant.  There's no point in checking for
_isnanf if we already have isnanf, for example.  (That optimization
won't help AIX because it has neither.)

More to the point, are their systems that really have acosf, and
asinf, but not atanf?  I bet not.

Below, I'll outline what I plan to do -- unless somebody stops me. :-)

I'm going to group these functions into bigger amalgamations and just
produce all-or-nothing results for the whole amalgamation.  That
should reduce the per-function cost substantially.

Also, <ctype> detection alone takes a long time (over a minute) to
work out.  Why are we doing this with autoconf (in a rather hacky way,
involving checking for funny symbols in ctype.h) rather than using
configure.target, like we do for other obscure properties on the
target?  I'm going to change that too.

(I suppose that we could even do that for all the math stuff too, but
that seems like a much more legitimate use of autoconf to me.)

Objections?

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


More information about the Libstdc++ mailing list