Re: Error cross-compiling lib/libc/rpc/svc_vc.c

FFFFFFFOn Tue, 13 Dec 2005, Johnny Billquist wrote:

> Date: Tue, 13 Dec 2005 03:52:55 +0100
> From: Johnny Billquist <johnny.billquist@xxxxxxxxxx>
> To: James Chacon <jmc@xxxxxxxxxx>
> Cc: Dave McGuire <mcguire@xxxxxxxxxxxxx>, port-vax@xxxxxxxxxx
> Subject: Re: Error cross-compiling lib/libc/rpc/svc_vc.c
>
> 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@xxxxxxxxxxxx           ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

--
As long as people believe in absurdities they will continue to commit
atrocities.  -Voltaire