>>> use DESTDIR; don't build to /.
>> I've tried that.  Didn't work that way either.
> there is something very wrong with your setup.

I noticed. :-)

> unfortunately, i don't know what the hell it is.  what, exactly, did
> it try to do when it failed to c++ compile stuff?

I managed to destroy the logfile, so I ran it all over again, from
scratch.

First, I made sure /usr/src was exactly and only what came from anoncvs
(minus the CVS/ subdirs - actually, minus anything with a basename
ending in "CVS").

Then, I threw away everything in /altroot.  Made it an empty directory,
owned by the same user who owns everything /usr/src.

Then, as that same user, in /usr/src, I ran

	./build.sh -d -D /altroot/build -O /altroot/obj -U

and it chugged along, building a bunch of tools and installing them.
Then, while doing the "make includes" step, it wanted to compile
something with c++, and fell over:

includes ===> gnu/lib/libstdc++
STRIP=/altroot/obj/tools/tools.NetBSD-1.6D-sparc64/bin/sparc64--netbsd-strip /altroot/obj/tools/tools.NetBSD-1.6D-sparc64/bin/nbinstall -U -M /altroot/build/METALOG -r -c -o root -g wheel  -m 444 /usr/src/gnu/lib/libstdc++/_G_config.h /altroot/build/usr/include/g++/_G_config.h
includes ===> gnu/lib/libstdc++/include
/altroot/obj/tools/tools.NetBSD-1.6D-sparc64/bin/sparc64--netbsd-c++ -O -ffixed-g4  -mcmodel=medlow  -Werror -nostdinc++ -isystem /altroot/build/usr/include/g++  -nostdinc -isystem /altroot/build/usr/include   -o /usr/src/gnu/lib/libstdc++/include/../../../dist/toolchain/libstdc++/valarray /usr/src/gnu/lib/libstdc++/include/../../../dist/toolchain/libstdc++/valarray.cc 
/usr/src/gnu/lib/libstdc++/include/../../../dist/toolchain/libstdc++/valarray.cc:1: std/std_valarray.h: No such file or directory
*** Error code 1

Stop.
nbmake: stopped in /usr/src/gnu/lib/libstdc++/include

Now, /usr/src/gnu/dist/toolchain/libstdc++/std/std_valarray.h exists.
But the #include uses < >, there's no option pointing the compiler at
anything under /usr/src, and it hasn't yet been installed into anywhere
under /altroot.

I also note that the compile is attempting to put the output executable
in the *source* directory(!!).

Looking at the Makefile in /usr/src/gnu/lib/libstdc++/include, I note

# This include file keeps the includes/build of libstdc++ separate,
# to avoid issues like "iostream.cc" using the default ".cc:" rule
# to build the "iostream" file (which is actually a header).

and it looks as though that's broken somehow.  valarray already exists
in the source directory, where the command is trying to put it; it just
happens to be older than valarray.cc.

This sounds very familiar.  The gperf problem was the same thing: a
source file and a generated file both in the source tree, and if the
timestamp on the generated file happens to be the older of the two, the
build procedure tries to run a command that it shouldn't.  It seems
there is a similar problem here.  I'll try touching valarray; I don't
doubt it'll fix this one, and another one will show up.

Maybe part of the testing procedure should be to randomize all mtimes
in the source tree (within, say, a ten-minute range) to catch this sort
of bug in the build procedures?  I'll be happy to write the
mtimes-randomizer program.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B