James Chacon wrote:
> 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.

No, we did not.
I remember when we didn't have a build.sh... :-)
And furthermore, the tools directory is passed through a few extra 
times, as is gnu/lib and some other places...

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

Yes. A number of times.

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

Yes.

>>And libc is just getting bigger and bigger.
> 
> I'll concede this. In 5 years it's gained abour 50% in overall size.

Thank you. And speed wise this really hurts. Just processing the 
makefile for libc takes a huge amount of time.

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

Probably true, but it seems as if it's getting more and more difficult 
to build and maintain the system if/when you decide to change what parts 
you want in.
I'm not even sure everything would work if you decided to skip some 
subsystems.
I've seen several reports of build.sh failing to do the work if you skip 
different parts. In fact, there are open PRs to that effect now, if you 
look.
So in real life it's not much of an option. :-(

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

You may take it anyway you want to. The basic fact is that building on a 
VAX, any VAX, is becoming so slow it's not doable soon. No matter if you 
call it FUD or not.

And building the whole 4.3BSD took about half a day. Have we really 
gotten that much improvements to motivate a build time increasing from 
12 hours to 7 days?
Don't even bother answering. I suspect you'll just call it more FUD 
anyway. The basic fact remains, NetBSD will soon not be usable on 
systems older than a few years because it requires too much processing 
power to do just a build, because it contains everything. So I stand by 
my original claim, I believe the VAX will soon not be supported anymore, 
since it's just too slow for the demands of the new versions of NetBSD.

Anyone remember the complaint about VMS? That it contained everything, 
and that was a major reason for bloat... Well, VMS is starting to feel 
pretty slim nowadays...

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

And so you don't even know that it won't build natively. Do you even try 
to boot the systems with new versions?

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

Don't know. I thorugh there was, but searching now I can't find any. 
There should probably be several:
One about build.sh not runnable. People reported it on this list several 
years ago, and I atleast told them that they could rerun the build 
several times until they got past the problem.
Another should be for the problem with gcc. Unfortunately, I haven't 
seen anyone come up with a good test case that will show the problem. I 
know that I stumbled over it while building kermit several years ago, 
and I know others have mentioned it in other circumstances.

I know I haven't filed any PRs on those, however.

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

Maybe. Don't know. groff is written in c++. You might hit memory limits 
if optimization is totally turned off, so that might not solve it. But 
otherwise -O0 might give a grn that don't dump core. I really haven't 
spent much time thinking about this. I've just gotten used to having to 
run build.sh several times.

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

As noone is building natively for the VAX, and this problem can't be 
seen by a cross build, I'm not expecting anyone to really fix it.

Looking at the open PRs for VAX, even simple stuff is left open, which 
suggests that there isn't much point in expecting anything to happen.
And as you said, gcc3 is a dead horse too.

Let's face it. NetBSD is becoming very big, partly by choice, and this 
is hurting slow machines. And blaming it all on gcc just don't cut it.

	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