Date: Mon, 27 Feb 2006 13:15:02 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: "M. Warner Losh" <imp@bsdimp.com> Cc: hackers@freebsd.org Subject: Re: world's toolchain & CPUTYPE Message-ID: <20060227101502.GJ6435@comp.chem.msu.su> In-Reply-To: <20060227.000317.123334621.imp@bsdimp.com> References: <20060226155009.GB6435@comp.chem.msu.su> <20060226185721.GF42677@ip.net.ua> <20060227.000317.123334621.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 27, 2006 at 12:03:17AM -0700, M. Warner Losh wrote: > In message: <20060226185721.GF42677@ip.net.ua> > Ruslan Ermilov <ru@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060227101502.GJ6435>