From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 27 07:03:56 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3725516A420; Mon, 27 Feb 2006 07:03:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A63A443D48; Mon, 27 Feb 2006 07:03:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k1R73EfJ065820; Mon, 27 Feb 2006 00:03:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 27 Feb 2006 00:03:17 -0700 (MST) Message-Id: <20060227.000317.123334621.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20060226185721.GF42677@ip.net.ua> References: <20060226155009.GB6435@comp.chem.msu.su> <20060226185721.GF42677@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 27 Feb 2006 00:03:15 -0700 (MST) Cc: yar@comp.chem.msu.su, hackers@freebsd.org Subject: Re: world's toolchain & CPUTYPE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 07:03:56 -0000 In message: <20060226185721.GF42677@ip.net.ua> Ruslan Ermilov writes: : On Sun, Feb 26, 2006 at 06:50:09PM +0300, Yar Tikhiy wrote: : > Hi all, : > : > Yesterday I hit the following problem: : > : > - was given an Athlon XP machine with a fresh CURRENT built with : > CPUTYPE=athlon-xp; : > : > - used it to build a fresh RELENG_6 world with no customizations : > at all -- __MAKE_CONF=/dev/null; : > : > - tried to install the world over NFS on an old Pentium machine : > with some 5.3-BETA; : > : > - "make installkernel" failed instantly because install(1) died on : > signal 4, illegal instruction. : > : > Quick investigation showed that the world was built using generic : > i386 code, as expected, but its toolchain was linked against the : > builder system libs contaminated by Athlon-specific code. It was : > sufficient to rebuild and reinstall all libs on the builder machine : > with no particular CPUTYPE set and then to rebuild the world's : > toolchain again to make the latter run well on the Pentium. : > : > I used to be under impression that a world's toolchain should be : > fairly independent from the builder system. However, this case : > showed that it wasn't quite true. Is it a known issue, or am I : > missing a key point? Thanks! : > : Simple answer: we just don't support installing "from" NFS, : but we do support installing "to" NFS. Any documentation : that says it's supported is lying. : : More details: during the install, part of the toolchain and : some special install tools that were built on the "build" : host are used. They have been built using that host's : toolchain, CFLAGS, libraries, etc., but libraries is the : most important factor. That means that the "install" host : should be CPU/syscall/etc. compatible with the "build" : host. When "build" == "install", all these conditions are : met. When CPUs match, kernels may be different enough so : there will be missing syscalls. And so far... I've never had issues with doing the install from NFS to a local disk. However, I make sure that all the make config variables are identical, the CPUTYPE is unset, and the systems are otherwise as identical as possible before trying. Also make sure that the file systems are mounted identically as well. I also try to set BOOTSTRAPPING=0 on the build host, which forces the maximum number of helper tools to be built. So while not strictly supported, it can be made to work if you know what you are doing, and take precautions, and live with the limitiations. Setting CPUTYPE falls outside the limitations in the build system. What's really fun is tricking the build system so you can cross build on one system, but native install on another from the same tree... Warner