Re: somewhat-auto-rebuilding libgcc.a with -fhonor-std

[Benjamin Kosnik <bkoz at cygnus dot com>]

> This happens in two stages:  we start with a skeleton ".in" script, and
> configure drops in what funky flags are being used (so that if namespaces
> are /not/ enabled, say, then this script will be a harmless timewasting
> no-op).  The second stage is just to drop in the correct invocation of
> "make" (won't know this until they actually invoke make).  Both of these
> changes are just a single sed.

The general approach seems to make sense. I wouldn't spend too much time
getting this to be super clean, as I think this is just going to have to
be kluged due to the current way g++ builds libgcc.a.

If you can, just make the libgcc.a rebuild conditional on a
--enable-runtime-rebuild=yes flag or something, and have it prompt
the user for the proper sym link to the gcc build (src?) directory (or
however you find it easiest to do the job).

If the end user doesn't specify this flag, then libgcc is not rebuilt,
period. This then gives us a way to enable -fhonor-std by default, and
then if somebody doesn't want it, they can re-configure with

--enable-runtime-rebuild=no

Obviously, docs will also have to change to support this.

> The not-as-good situation is when the gcc build directory has been blown away
> and there's nothing but source.  In that case, the library can be correctly
> rebuilt by following the procedure above through "make rebuildscript"
> and then fooling my braindead script into thinking we've been here before:

Or you can just mandate people using --enable-runtime-rebuild keep their
build (src?) dirs around. I don't see a problem with this.

Looks good. 

benjamin