Re: world's toolchain & CPUTYPE
- From: Yar Tikhiy <yar@xxxxxxxxxxxxxxxx>
- Date: Mon, 27 Feb 2006 13:15:02 +0300
On Mon, Feb 27, 2006 at 12:03:17AM -0700, M. Warner Losh wrote:
In message: <20060226185721.GF42677@xxxxxxxxx>
Ruslan Ermilov <ru@xxxxxxxxxxx> 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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- References:
- world's toolchain & CPUTYPE
- From: Yar Tikhiy
- Re: world's toolchain & CPUTYPE
- From: Ruslan Ermilov
- Re: world's toolchain & CPUTYPE
- From: M. Warner Losh
- world's toolchain & CPUTYPE
- Prev by Date: Accessing address space of a process through kld!!
- Next by Date: unversal watchdog
- Previous by thread: Re: world's toolchain & CPUTYPE
- Next by thread: Re: world's toolchain & CPUTYPE
- Index(es):
Relevant Pages
|
|
