Subject: Re: Error cross-compiling lib/libc/rpc/svc_vc.c
To: James Chacon <jmc@NetBSD.org>
From: Johnny Billquist <johnny.billquist@softjar.se>
List: port-vax
Date: 12/13/2005 03:52:55
James Chacon wrote:
> On Tue, Dec 13, 2005 at 03:00:07AM +0100, Johnny Billquist wrote:
> 
>>James Chacon wrote:
>>
>>>On Tue, Dec 13, 2005 at 01:24:58AM +0100, Johnny Billquist wrote:
>>>
>>>>James Chacon wrote:
>>>>
>>>>>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... :-)
> 
> So do I and I'm reading the Makefile from 1.5.
> 
> It clearly (in make build) does a tree pass of cleandir, a tree pass of 
> make obj, includes, builds lib, etc and installs it and then does a 
> complete pass again with dependall.

I didn't do a make build. I don't remember when make build appeared, but 
I don't even think it existed at the time I started using NetBSD.
I have actually never used make build myself, as far as I can remember. 
I finally switched over to using build.sh around the 1.6 or so.

>>And furthermore, the tools directory is passed through a few extra 
>>times, as is gnu/lib and some other places...
> 
> gnu/lib always was.

Not for me. But I guess you can understand that from above.

>>>build.sh just calls make in the end....
>>
>>Yes. A number of times.
> 
> I actually doubt it's more than 1 extra pass in the end and even then most
> of the passes are optmized now to not go any deeper than they need to.

I admit that this has improved a lot from a year or two ago, when we had 
a separate pass for "depend", followed by the "all" targets, and other 
extra passes that I've probably forgotten about.
But it still is heavy work.

>>>>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.
> 
> Ok, so you want the system to be what it was in 1995 basically. Just come out
> and say that then. You clearly claimed in your original email it was "stuff
> from the last year", yet all your examples of *bad* stuff are 5+ years old.

You must read rather sloppy. Or how did you miss pam and NLS?

> If PR's get open they get fixed in general. Maybe not right away but that's
> the only way we know. The hooks aren't put in so they can't be used. They're
> put in so people can use them. If you chose not to, and then complain about
> how you're getting all this stuff you don't want I really don't have an
> answer for you...

Sigh. So I complain that building takes for ever, and a big reason is 
that the system now contains so much more than in the past. You point 
out that much can be skipped. I point out that this will result in 
build.sh failing.
And the answer to that is basically: tough luck. It should work. Wait 
for a while, and maybe you can build the system.
That's really comforting. So instead of waiting a week or two to have a 
new system, I should wait a couple of months or so.

>>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.
> 
> Got a modern example of anything that slowed it down significantly? Something
> in the last year+? Again...all your examples come down to "in the good old
> days of 4.4lite it was great!".

I don't know why I get dragged into this discussion every time I mention 
that the system is becoming larger and slower to build.
Every time I get the response from people that I should blame gcc. Noone 
seem to be willing to actually admit that NetBSD has grown a lot, and 
keep growing and that this hurts performance and builds. Heck, even 
though you yourself admit that libc has grown by 50% (it would be 
interesting to know by which measure that is, by the way), you still ask 
me for examples of things that has slowed down the build. Well, apart 
from the growth in libc, you have (as I mentioned) pam and NLS for 
instance. Moving over to having everything linked dynamically also is a 
performance hit, which I suspect is quite measurable when running so 
many processes as the build are.
Hmm, just moving the tools over to static linked images might actually 
give some gains. But this is just some educated guesses. I haven't done 
any measurements.

>>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.
> 
> Really? It's not usable or just can't be easily natively compiled? I've
> yet to hear anything claiming it's becoming unusably slow.

The VAX 8650 is far from the slowest VAX you can find, and yet, doing 
just a "build.sh build" will take about a week, and then you also have 
to restart it three times, which adds more time.
How slow does it need to be before becoming unusably slow? A month for a 
build? A year? We're probably soon getting there on the slower machines 
available.

>>>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.
> 
> not runnable? I don't understand here. If builds crash people should file
> PR's. Thats the only way things will get fixed long term.

Certainly.
I'll file a pr right away to make you happy.

	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