From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 00:20:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 547D216A4CE for ; Wed, 24 Mar 2004 00:20:55 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62B0243D54 for ; Wed, 24 Mar 2004 00:20:54 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i2O8Nv8b049505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2004 10:23:58 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2O8KnHk041366; Wed, 24 Mar 2004 10:20:49 +0200 (EET) (envelope-from ru) Date: Wed, 24 Mar 2004 10:20:45 +0200 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20040324082045.GA41172@ip.net.ua> References: <20040324012315.GA40315@xor.obsecurity.org> <20040324065815.GA40963@ip.net.ua> <20040324070256.GA44741@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20040324070256.GA44741@xor.obsecurity.org> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Kris Kennaway Subject: [FAQ] Prerequisites for a successful buildworld/buildkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2004 08:20:55 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [I thought I would publish this once again, as I regularly have to answer these questions.] ;) The below talks about the prerequisites for a successful build (world and kernel). On Tue, Mar 23, 2004 at 11:02:56PM -0800, Kris Kennaway wrote: > On Wed, Mar 24, 2004 at 08:58:15AM +0200, Ruslan Ermilov wrote: > > On Tue, Mar 23, 2004 at 05:23:16PM -0800, Kris Kennaway wrote: > > > This guy doesn't seem to have a full /usr/include (e.g. it's missing > > > db.h), but he claims to have done a buildworld before buildkernel, > > > which fails due to the missing db.h. Shouldn't buildkernel be using > > > the internal set of headers prepared by buildworld, instead of relying > > > on the outdated host environment? > > >=20 > > Yes, src/sys/ is self-sufficient, except for some tools used during > > buildkernel, aicasm is one of them. >=20 > ...which was the content of my question. So, upgrades (buildworld > then buildkernel) apparently don't work if you don't have /usr/include > installed to begin with. >=20 Of course not. For a successful buildworld (and buildkernel), it is required to have a complete and non-broken build system, as we still build lot of tools using the host toolchain. Under "host toolchain" we mean what's installed now: compiler, binutils, headers in /usr/include, libraries in /usr/lib (and /lib in 5.x), yacc(1), lex(1), install(1), etc. Tools that are built using the host toolchain are: - bootstrap-tools, those that have known backward compatibility issues. For example, when a new option is added to install(1) and we start using it in src/ makefiles, we need to upgrade install(1) so that we can use it during installworld and installkernel. The reason why it should be built using host toolchain should be obvious: - we're going to _run_ the new install(1) binary under the currently running kernel, which may not contain all new syscalls that may be in the new libc. - we may be building for a different target architecture. - cross-tools, those that have a notion of TARGET_ARCH, and produce different output for different target architectures; the most known of them are C compiler and binutils. We configure them to run on the current machine, using the currently running kernel and libraries (host toolchain), but produce output understood by a target machine, possibly of a different hardware architecture. - build-tools. These are special small helper applications that are built and used only during buildworld/buildkernel. For example, "mkinit" for bin/sh and "aicasm" for the Adaptec SCSI drivers. Once we get that far, we build the rest with MACHINE_ARCH set to TARGET_ARCH. We use these newly built *-tools to complete the target toolchain: build/install headers, then libraries, to a temporary location (WORLDTMP) known to cross-tools. Now that we have a complete target toolchain, we use it to build the rest of the world/kernel. (The build(7) manpage badly needs to mumble something about the prerequisites for a successful buildworld/buildkernel.) Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAYUTdUkv4P6juNwoRAoLTAJ9QXS2e9nyaFRHTle/ky7CKJ48WAACdHSID 1XipiYXrcyX9UYNsmp5Gb8o= =pB+X -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7--