From owner-freebsd-current Mon Jan 29 13:09:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA03470 for current-outgoing; Mon, 29 Jan 1996 13:09:54 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA03461 for ; Mon, 29 Jan 1996 13:09:44 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA09260; Mon, 29 Jan 1996 14:11:39 -0700 Date: Mon, 29 Jan 1996 14:11:39 -0700 From: Nate Williams Message-Id: <199601292111.OAA09260@rocky.sri.MT.net> To: Richard Wackerbarth Cc: Nate Williams , current@freebsd.org Subject: Re: I'm rather annoyed with -current. In-Reply-To: References: Sender: owner-current@freebsd.org Precedence: bulk > Nate Williams writes: > > >You need to build and install rpcgen *before* the include files are > >built. There is also a dependency problem with either the libraries or > >the crt0.o file (I don't remember which one is first.) > > > >It basically boils down to the fact that we *should* be building the > >sources out of the src tree and not out of the stuff in > >/usr/{lib|include} etc... (Which I've argued against in the past as > >un-necessary and complex, but I think we've now reached critical mass > >and require it.) > > Now, while we are at it, will you also agree that we should not be using > the tools in /usr/bin either? Unfortunately, we *have* to use them. You can't build a c-compiler w/out a C-compiler. Obviously, all of the support tools that go along with are also important. > In particular, there are three (logical) systems to consider. > > A. The host > B. The cross-compiler > C. The target > > "make world" runs through everything twice in order to produce both "B" and "C". > In the process, it trashes "A". If we recognize that each pass of "world" > is really just like a compilation of one tree, we can do everything with a > straight forward "make". While I agree in theory, I don't think we can make it all work in one simple 'make'. You *must* assume certain programs exist, and they must exist prior to a system build. This in itself isn't a problem, but it is not only possible but highly probably that remaining parts of the system (including the tools themselves) should be built using themselves. > First we make the tools into the object tree and then we turn around and > make the target binaries using those tools. True, but we still have the same problems as before. We update our C-compiler to avoid the -O2 strength reduce bug. For this arguement, let's assume we can't avoid the bug with compiler flags. In order to fully guarantee that the bug is irradicated from the system, we must first build gcc using the buggy compiler. Then, we should rebuild gcc again using the newly built gcc (which won't work in the current model since you can't over-write running binaries). Then, the final gcc built should be used to build the rest of the tools. We still have the same dependency problems that the current system has, except that in the solution that doesn't yet exist, we don't clobber the hosts system. > Since we want to fold the sources, we need to have "make" look into the > tree for the current definition of the tools like rpcgen. Again, the dependencies are still there. We still have to build rpcgen before we can build the include files. I guess I may be thinking that changing the tools to build in-place is a good thing on paper, but I don't see it solving any of the existing problems we have. Nate