James Chacon wrote:
> On Sat, Dec 10, 2005 at 05:48:53PM -0500, Dave McGuire wrote:
> 
>>On Dec 10, 2005, at 5:36 PM, Johnny Billquist wrote:
>>
>>>I suspect before long, the VAX won't even be supported any more. It's 
>>>been several years since you last could run build.sh from start to 
>>>finish on a native build on a VAX. And all the new stuff they keep 
>>>adding just means it's getting slower and slower, for almost no return 
>>>(in my view). Building on a VAX 8650 now takes over a week for just 
>>>/usr/src.
> 
> I'd be interested to pinpoint examples here. I'll almost bet that's the
> compiler getting slower. It's been fairly well documented that as gcc goes
> up in versions the slower it gets.

Oh. The fact that we now use build.sh, which runs over the same 
directory tree a number of times definitely hurts a lot.
The libcrypto stuff that was included some time ago really added one day 
or two to a build on my 8650.
And libc is just getting bigger and bigger.
pam added yet another 12 hours or so. And pam I could really live 
without. NLS support is another of these things that really drags things 
down more, and that I'm not interested in either.

This is all my personal views of course, but they are all things that 
makes a build much slower, and you can't just blame it all on gcc. Yes, 
gcc is slower, but the fact is that all the cruft that NetBSD has 
nowadays is much worse for adding time than gcc is.

Actually, just building the tools will take me almost 24 hours.

> Otherwise vax has built from build.sh (cross mind you since I don't often
> build native) on every release we've ever done in recent memory and will
> on 3.0 as well. Just because it's broke on -current "right now" doesn't
> equate to "over a year"...

I know. And that is the problem. There is a bug in the gcc/VAX, which 
you don't see when you do cross compiles. I'm telling you (and I have 
said it in the past). A native build on a VAX have not worked for years, 
and that is literally years. Probably close to five by now.

The specific problem you hit upon is that when the tools build comes to 
groff, it will fail late in the build, when creating some document, 
because grn segfaults.

If I were to guess that is because some code generated by gcc is wrong 
when using -O2. Nobody ever seems to try to find the problem, but it has 
been verified that using -O0 in those few cases where it happens will work.
I found it while building one file in kermit as well.
It's rare, but it do happen occasionally.

But I haven't verified it definitely for this case with grn.
The solution for now is to rerun build.sh when it crashes, but remember 
to include "-u" for the reruns. I think you need to run it three times 
before you're clear of the hurdle.
Each time it crashes, it will actually create a small resulting file, so 
the next time around, the build will proceed to the next item to build, 
so we're not getting totally stuck at the crashing point in the build.
(Of course, just creating the expected output file, even as an empty 
dummy, would also get us by.)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol