From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 27 10:15:18 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 2066316A420; Mon, 27 Feb 2006 10:15:18 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2DDA43D48; Mon, 27 Feb 2006 10:15:14 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id k1RAF3X9031707; Mon, 27 Feb 2006 13:15:03 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id k1RAF3X7031702; Mon, 27 Feb 2006 13:15:03 +0300 (MSK) (envelope-from yar) Date: Mon, 27 Feb 2006 13:15:02 +0300 From: Yar Tikhiy To: "M. Warner Losh" Message-ID: <20060227101502.GJ6435@comp.chem.msu.su> References: <20060226155009.GB6435@comp.chem.msu.su> <20060226185721.GF42677@ip.net.ua> <20060227.000317.123334621.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060227.000317.123334621.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: 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 10:15:18 -0000 On Mon, Feb 27, 2006 at 12:03:17AM -0700, M. Warner Losh wrote: > 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. Thank everyone for clarifying this issue! I was short-sighted. Indeed, the toolchain is to work on the builder host in the first place, so it should use the builder's MACHINE_ARCH, CPUTYPE, etc. Therefore it won't be generally possible to run it on the target 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... I wondered, too, if it would be possible to cross-build install tools so that they could run on the target system, but I haven't investigated this way yet. Do you have any ideas/recipes? Thanks! -- Yar