Date: Mon, 29 Jan 1996 14:11:39 -0700 From: Nate Williams <nate@sri.MT.net> To: Richard Wackerbarth <rkw@dataplex.net> Cc: Nate Williams <nate@sri.MT.net>, current@freebsd.org Subject: Re: I'm rather annoyed with -current. Message-ID: <199601292111.OAA09260@rocky.sri.MT.net> In-Reply-To: <v02140b05ad32db40927c@[199.183.109.242]> References: <v02140b05ad32db40927c@[199.183.109.242]>
next in thread | previous in thread | raw e-mail | index | archive | help
> Nate Williams <nate@sri.MT.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601292111.OAA09260>