Ben Harris <bjh21@netbsd.org> wrote:
 
> So that was building the toolchain the second time, rather than building gcc
> for installation into the target system.  That means it should have happened
> _before_ the new kernel headers got installed.  If you've got a complete log
> of this build, could you look for mentions of sys/times.h occurring before
> this point?

Sorry, I foolishly put the log in /tmp, which got wiped after a reboot.

> Did the log at the top come from the first failed build or a later one?  If
> it came from a later one, I think I know what happened.  You managed to get
> an inconsistent CVS update which included the sys/times.h changes to add
> __times13(), but not the libc changes.  On your first build, the new headers
> and the slightly older libc got installed, and when the build got round to
> building the native GCC (which I think is the first application that uses
> times()), it failed.  Future builds, starting from scratch, will have failed
> earlier, because they had the header/library inconsistency from the start.

Yes, that's what I see here.

> The way to fix this (without resorting to downloading binaries) would have
> been to manually update and recompile libc, with USETOOLS=no if necessary.

Thanks - I did download and isntall comp.tgz, and the momentarily
running build seems to get beyond thæt point, so I'm hopeful it
completes.

I'll post again when I have anything to report, hopefully more details
should something go wrong.

-Jan

-- 
A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools.