[ i've already meantioned most of this to jason on ICB, but
i wanted to be sure we didn't forget about my comments. :) ] 


   There are also two platforms that I am mostly ignoring in this document:
   ia64-netbsd and hppa-netbsd.  The IA64 port is only in the beginning
   stages, and the HPPA port has not been committed the source tree, yet,
   so I don't have any way to test any of its toolchain components.

mmm vapourware :)
   
   Also, I am the "NetBSD host and target maintainer" for both GCC and
   GDB, and I have commit privs to the master CVS repositories for GCC,
   Binutils, and GDB.  If you need need to make changes to the toolchain,
   you should discuss them with me, first.  And if you are going to make
   a non-trivial change, then I will insist that you take care of getting
   FSF copyright assignments filed, otherwise I cannot commit your change
   back upstream, which puts us back in the same unpleasant situation we've
   been in for years.

this i could not agree more with.
   
   The NetBSD OS currently uses the following versions of the GNU toolchain
   components:
   
   	GCC 2.95.3 + local patches (mostly target support)

actually, there are significantly non-target support changes...
   
   	GDB 5.1 + local patches (mostly target support)

you mean GDB 5.0.
   
   		mips*-netbsdelf
   		sparc64-netbsdelf (requires -D_LP64 patch)

these are just "mips*-netbsd" and "sparc64-netbsd" (i'm sure of the
latter, but not sure on the former.)
   
   		GCC 3.2 is scheduled for release in December 2002.  It
   		may be acceptable to import development versions of the
   		compiler into the tree to track until the 3.2 release
   		is made, so long as we do not ship an actual NetBSD release
   		with a non-release compiler.

"please no."
   
   	1. Anoncvs update to the selected version of the toolchain
   	   component from the appropriate anoncvs server:
   
   		a. gcc.gnu.org for GCC (tip-of-mainline until 3.2 is
   		   branched, then track that branch is made).
   
   		b. sources.redhat.com for Binutils (either select a
   		   release and slurp it down once, or track to 2.12
   		   release branch).

you may consider using this CVSROOT, which contains a read-only merge
of the GCC & binutils/GDB trees (gcc.gnu.org == sources.redhat.com,
BTW) much like our own and the one at my work:

	:pserver:anoncvs@gcc.gnu.org:/cvs/uberbaum
   
   	3. For each $MACHINE_ARCH for which a test build will be
   	   done:
   
   		a. Build a cross-targeted binutils.
   
   		b. Build a cross-targeted gcc.

this falls into a single step, given we switch to using uberbaum.
   
   	3. Perform a GCC bootstrap.  This is a 3-stage build of the
   	   compiler:
   
   		a. Builds stage1/xgcc with /usr/bin/cc -O0.
   
   		b. Builds stage2/xgcc with stage1/xgcc -O2.
   
   		c. Builds stage3/xgcc with stage2/xgcc -O2.
   
   		d. Does a byte-for-byte compare of stage2/xgcc
   		   and stage3/xgcc, failing if they are not
   		   identical.

i will note that this builds only one copy of libiberty, by the original
bootstrap compiler (ie, cc -O0!), which is linked into each stage.  as
significant parts of GCC are in libiberty, i'd suggest that we avoid
"make bootstrap" and use own own script that installs each stage and
re-configure/re-builds everything or change "make bootstrap" to build
libiberty each time but this seems much more non-trivial.


.mrg.