Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Oct 1999 13:48:57 +0200
From:      Marcel Moolenaar <marcel@scc.nl>
To:        arch@freebsd.org
Subject:   Re: make world issues
Message-ID:  <38086629.848BC1BF@scc.nl>
References:  <380716A4.20961526@scc.nl>, <19991016211449.H67481@freebsd1.cimlogic.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell wrote:
> 
> On Sat, Oct 16, 1999 at 12:50:09PM +0200, Marcel Moolenaar wrote:
> > John Birrell wrote:
> > >
> > > I don't think that cross-compilation helps solve the bootstrap/upgrade
> > > problem caused by the signal changes.
> >
> > I think it does. Please explain to me why you think cross-compilation
> > doesn't solve bootstrapping/upgrading.
> 
> Because when cross-compiling, you don't execute anything that you
> build for the target system.

I don't disagree on that :-)

> By contrast, for the host build, you need to update things in bootstrap
> order and then progessively execute the updated things in order to
> complete the build.

This is perfectly fine, as long as you use the native headers and
libraries for building the bootstrap tools. This is what's wrong with
our current build process. If you fix this, you can build releases for
Alpha on i386 or build an IA64 world without actually having FreeBSD on
IA64 yet.

> If you make a change (like the signal changes)
> that isn't backward compatible, then you can't bootstrap properly
> because you can't execute what you build.

You said a couple of lines above:

\begin{quote}
> Because when cross-compiling, you don't execute anything that you
> build for the target system.
\end{quote}

I don't have anything to add to that :-)

> You shouldn't blame the build process for it's inability to handle
> the lack of backward compatibility in your code. We shouldn't allow
> changes to libc that won't work with older kernels.

I disagree. The build process is clearly at fault for mixing tool builds
with target builds. Bloating libc is not a solution; it's a work-around.
This implies that the bug is still their and it's going to bite you
again (and again). And worst of all, in 20 years time FreeBSD will be
the bloatest and slowest and most unstable OS on the world, because libc
will have most of the kernel duplicated in userland simply to have it
run on an archaic kernel for an (as then) obsoletedarchitecture...

No. libc should be lean and mean, with only necessary compatibility
added to it -- source compatibility that is, not kernel compatibility.

footnote: IMO, of course :-)

-- 
Marcel Moolenaar                        mailto:marcel@scc.nl
SCC Internetworking & Databases           http://www.scc.nl/
The FreeBSD project                mailto:marcel@FreeBSD.org




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38086629.848BC1BF>