slow V3 configures (was Re: ICE during bootstrap.)

[Phil Edwards <pedwards at disaster dot jaj dot com>]

[bringing the v3 list into this]


On Tue, Dec 05, 2000 at 10:05:27AM -0600, Robert Lipe wrote:
> 
> Is the configure cycle for the v3 stuff this painful for everyone?
> It spins through screens and screens of 
> 	checking for finite declaration... (cached) yes
> 	checking for finite... (cached) yes
> 	checking for copysign declaration... (cached) yes
> 	checking for copysign... (cached) yes
> 	checking for sincos declaration... (cached) no
> 
> even cached, these take a little over a second each and in total consume
> several minutes.

We're pretty certain that those all need to be there, I think.  Whenever we
start making assumption about "if foo() is there, surely bar() is also
there," it breaks on somebody's platform.

Still, that configure script in general is one of my back-burner pet peeves.

At the beginning of September, I /almost/ sent the following email to the
v3 list.  I postponed it instead and never got back to it.

============================================================
    To: libstdc++@sources.redhat.com
    Subject: All C++.  All the time.

    No, the Subject: is not an advertisement for yet another special-topic
    television cable channel.

    In June I posted a note regarding the massive size of our configure
    script.[*]  And I think Gaby was right; lots of that is due to all
    the math function checking (striping those out reduces the script size
    from over .5 MB to around 162 KB).

    Also, running that section of configure is slow, even when the values
    are cached.

    The checks themselves aren't that big nor that time-consuming.  But we
    do a lot of LANG_SAVE, LANG_CPLUSPLUS, LANG_RESTORE during those checks,
    and elsewhere, which continually messes with the same shell variables
    over and over.  (That's what's causing those abrupt pauses during the
    already-cached tests; pushing and popping the same values some four
    or five dozen times.)

    Why don't we factor out all that stuff and enclose the entire
    configure in LANG_CPLUSPLUS?  As far as I can tell, only the
    GLIBCPP_CHECK_MATH_SUPPORT checks must not use this mode (they're C++
    but without the C++ library being linked in, for obvious reasons).
    There are probably a few others that I'm forgetting.

    I submit that those are the exceptions rather than the rule.  For the
    math support, we already just tweak the appropriate cxxflags.  If there
    are tests that /must/ be run as C rather than C++, then we can enclose
    /those/ in LANG_SAVE, LANG_C, LANG_RESTORE.


    If I'm completely insane here, please remind me what I'm forgetting.


    Phil
    [*]  http://sources.redhat.com/ml/libstdc++/2000-07/msg00208.html
============================================================

That email is a little out of date.

At the time, I had made those changes to my local tree -- configure times
did go down -- and was experimenting to see what changed with regard to
autoconf results.  I got as far as "good, not much changed."

It seems that AC_FUNC_MMAP must be done as C, not C++.  One or two of
the math tests got different results, at least on Solaris 8, and I was
looking into those when more important v3 stuff started happening/breaking.
I never got back to this.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.