Folks,

I think we have hit a generic gcc configure bug. Michael Lorenz discovered
that after my changes to default sparc64 to cpu=ultrasparc we can not build
NetBSD/sparc on a NetBSD/sparc64 host anymore.

The problem is this part of gcc's configure.in:

# Decode the host machine, then the target machine.
# For the host machine, we save the xm_file variable as host_xm_file;
# then we decode the target machine and forget everything else
# that came from the host machine.
for machine in $build $host $target; do
	. ${srcdir}/config.gcc
done

Now config.gcc sets various variables, but some of them not all the time.
My change (copied from the configurations for FreeBSD and OpenBSD) sets
with_cpu=ultrasparc.

When running above loop, we aquire $with_cpu=ultrasparc and then do the
last pass for the target, sparc--netbsdelf. The sparc case does use 
$with_cpu w/o any initialization in our src/tool build.

So guess what happens: we build a sparc compiler with -mcpu= defaulting
to ultrasparc. Since for the sparc build binutils is compiled as 32bit-only,
the resulting toolchain can not compile any program.

As a brute-force solution I would suggest this patch:

Index: configure.in
===================================================================
RCS file: /cvsroot/src/gnu/dist/gcc/gcc/configure.in,v
retrieving revision 1.4
diff -u -r1.4 configure.in
--- configure.in	10 Feb 2004 12:56:21 -0000	1.4
+++ configure.in	17 Nov 2005 07:32:53 -0000
@@ -881,6 +881,7 @@
 # then we decode the target machine and forget everything else
 # that came from the host machine.
 for machine in $build $host $target; do
+	unset with_cpu
 	. ${srcdir}/config.gcc
 done
 

Comments?

Martin