Subject: Re: World build failure in netbsd-2-0 and current
To: None <firstname.lastname@example.org>
From: Dmitri Nikulin <email@example.com>
Date: 11/04/2004 15:18:57
A few quick replies:
Omitting -pipe did nothing, just slowed things down visibly.
This was a clean source tree and clean install, as I already
mentioned... the source tree was fetched to a directory that didn't even
exist yet, and the install had not had any messy updates... and was a
2.0 RC4 snapshot (all have worked in the same way, but this was the last
of the i386s on the releng.netbsd.org server before it went down). So as
far as I can tell, everything was as Right as it could have been.
To summarise, the only way I could get the build moving was to copy the
generated includes from where they were to where they would be included
from. I believe this to be because, in my particular case, nbmakedep
does not imply -I. even for ""-included headers (as opposed to <>).
Trying David's line now, (had to move update to before -I - cvs flag
parsing 'feature') seems to be cleansing quite well, but I don't yet
know how this will affect the build... since the tree was 'clean' when I
fetched it, and there was nothing in /usr/obj either.
I'm still stumped on why it happens though. Yes, I have used build.sh
for 80% of my build attempts, and no matter how I used it, by the book
or by the help, nothing was any different.
Let's say that, on a completely fresh install with all usual sets, this
would be my strategy (assume basic configuration and all that is done):
(All as root - could THIS be a problem?)
setenv CVSROOT firstname.lastname@example.org:/cvsroot
setenv CVS_RSH ssh
cvs -z5 checkout -rnetbsd-2-0 -P src
./build.sh tools distribution install=/
(Well, usually I build a kernel *first*, but this doesn't have any real
As far as I can tell, the cvs stage is not the problem, because the same
problems occur with sources unpacked from tarballs, or even CVSup'd from
either of the two mirrors.
Anything horribly wrong with that procedure, which would warrant