March gcc 3.0 and 3.1 Bootstraps Fail 34% of Time

[Zack Weinberg]

On Tue, Apr 03, 2001 at 11:48:23AM +1000, Fergus Henderson wrote:
> On 02-Apr-2001, Nathan Sidwell <nathan@codesourcery.com> wrote:
> > This month I've had gcc users (who've had good reasons to want the latest
> > CVS) ask me which date they should check out of CVS to get a build,
> > because they've been unable to bootstrap.
> 
> I think part of the answer to that should be to suggest a tag, e.g.
> `-rgcc_latest_snapshot', rather than a date.  Unfortunately last time I
> looked that only worked for the 3.0 branch, not the trunk, since there's
> no "known to bootstrap" tag for the trunk.
> 
> (But I agree that the number of failing bootstraps is much too high.)

Note that the last three problems I noticed which caused bootstrap or
'make check' failures were: a horrible makefile mess, a bug in the
assembler, and an unportable shell construct.

I don't know that anything could have been done about the assembler
bug - well, we could tighten up the check for .uleb128, but I don't
know that it's necessary; people tracking either binutils CVS, or HJ's
patch series, should know they have to update often.

The horrible makefile mess was a case of unforeseen consequences.
Backing out the patch that caused it might have been a good idea; on
the other hand, then it might have gone unfound longer because fewer
people would have looked at it.  I probably wouldn't have, for
instance.

The unportable shell construct is perhaps the only one that could
easily have been caught before checkin.  Linux systems tend to have
bash for /bin/sh.  If you want to write portable shell, however, you
should change that.  Get ash from Debian and install that as /bin/sh.
There is a nice fringe benefit: shell scripts will all run at least
twice as fast.  But be careful, doing this can break system scripts.
Debian's are pretty good, and still I file a couple of bugs every
month due to bashisms in init.d or post-install scripts or whatever.

ash is the *BSD /bin/sh (sort of), so people using those systems don't
have to worry so much.  If you work on Solaris or other commercial
Unix, just make sure you've not got bash for make's SHELL.

I do get the impression that people tend to ignore regressions in
front ends other than the ones they're currently hacking.  This is
especially the case when the entire tree doesn't build.  libjava just
went from 3 to 300 unexpected failures in one week, and libstdc++ is
in bad shape although I'm not sure how long it's been that way.

One final note: perhaps right now we shouldn't worry about the
mainline quite as much.  3.0 branch is the place where breakage is
catastrophic.  Yeah, if the mainline doesn't build it's harder to get
bleeding edge work done, but 3.0 needs more attention anyway...
(I shouldn't talk :-)

zw