On Tue, Dec 13, 2005 at 01:24:58AM +0100, Johnny Billquist wrote:
> 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.

Umm..we always did. Make obj always ran before make includes and both
scanned the entire tree.

build.sh just calls make in the end....

> The libcrypto stuff that was included some time ago really added one day 
> or two to a build on my 8650.

libcrypto added back around 1.5? (or even before). This is like 5 years ago...

> And libc is just getting bigger and bigger.

I'll concede this. In 5 years it's gained abour 50% in overall size.

> 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.

You can chose to not compile these in as well if you're compiling yourself.

MKxxx=no

> 
> 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.

I see most of your statements as FUD honestly. A majority you highlighted
were things that have been there for a long long time. Yes, things take longer
but you're also using a machine that hasn't exactly been known to be speedy
for a long long time either. I honestly view this along the same lines as
people wondering why native compiles on their sun2/sun3 take forever. It
never was fast, so *anything* adding to it will appear worse and it's only
magnified when you're using hardware that was last current in 1989.

(and yes, I own a bunch of this stuff too...I just don't torture myself
by compiling native all that much. I know it'll take weeks).

> 
> 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.

Is there a PR for this?

> 
> 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.

There's many problems with that compiler on vax but until we get to gcc4
there's little that can be done except work around things by turning down
optimization on specific things, etc.

In this case it would make no difference really to have HOST_CFLAGS=-O0
for groff on vax for instance.

> 
> 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.)

Again, is there a PR for this? Thats the best way to getting stuff like this
fixed.

James