Subject: Re: more build funzies
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 07/24/2002 13:45:54
>>> 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
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
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
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
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B