From owner-freebsd-arch Sat Oct 16 4:54: 1 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 64CDC15490 for ; Sat, 16 Oct 1999 04:53:58 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA21722 for ; Sat, 16 Oct 1999 13:53:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA57308 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 13:53:57 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 12B4C15490 for ; Sat, 16 Oct 1999 04:53:50 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id NAA59177 for arch@FreeBSD.org; Sat, 16 Oct 1999 13:49:04 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Sat, 16 Oct 1999 13:48:57 +0200 From: Marcel Moolenaar Message-ID: <38086629.848BC1BF@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <380716A4.20961526@scc.nl>, <19991016211449.H67481@freebsd1.cimlogic.com.au> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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