world's toolchain & CPUTYPE
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! -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: world's toolchain & CPUTYPE
yt> - tried to install the world over NFS on an old Pentium yt> machine with some 5.3-BETA; AFAIK, the only 'supported' installation mode is to have the installworld step running on the same machine that did the build. I.e., you need to export '/' from the old Pentium box, mount it somewhere on your Athlon and run a make installworld (on the Athlon) with the appropriate DESTDIR value. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: world's toolchain & CPUTYPE
On Sun, 2006-Feb-26 18:50:09 +0300, Yar Tikhiy wrote: >- tried to install the world over NFS on an old Pentium machine > with some 5.3-BETA; This isn't supported in general. It should work if: - Both the buildhost and install target are running the same OS date - The installed OS on buildhost was built to the lowest common denominator of both hosts (ie CPU_TYPE=pentium or lower in your case) - src and obj have the same absolute pathnames (including symlink expansions in src). The supported approach is to NFS mount the target onto the buildhost and use "make DESTDIR=/target installworld" >Quick investigation showed that the world was built using generic >i386 code, as expected, Good. > but its toolchain was linked against the >builder system libs contaminated by Athlon-specific code. Also, as expected. >I used to be under impression that a world's toolchain should be >fairly independent from the builder system. Not true. The buildworld toolchain is a cross-compilation system designed to run on the existing host OS version whilst building executables that will run on the target OS version. Of necessity, the toolchain compiles and links against the installed include files and libraries on the host system. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: world's toolchain & CPUTYPE
On Mon, Feb 27, 2006 at 05:24:42AM +1100, Peter Jeremy wrote: [...] > The supported approach is to NFS mount the target onto the buildhost > and use "make DESTDIR=/target installworld" > ... and to make it work, make sure to "chflags -R noschg" the target / on the target host first. (I upgrade all my animals in a zoo this way, from the Hammer.) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplC58AqacEg.pgp Description: PGP signature
Re: world's toolchain & CPUTYPE
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... Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpSNCOcrJOOg.pgp Description: PGP signature
RE: [PATCH] does ukbd delay break scan codes?
> > yes I too looked at ukbd code and found the same. > > I already put a patch on the bug list yesterday. > > good. does it fix your problem, i.e. keyboard freeze? if it does then i > can commit it for you. It doeos at least for me and my environment (FreeBSD 4). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: world's toolchain & CPUTYPE
In message: <[EMAIL PROTECTED]> Ruslan Ermilov <[EMAIL PROTECTED]> 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
