Ken Moffat wrote: > On Tue, May 29, 2007 at 03:04:37PM -0400, Joe Ciccone wrote: > >> >>> >>> >> One thing you have to watch our for is that the final system is built by >> the output of config.guess. which relies on uname -m. If your host is >> running a x86_64 kernel chances are uname -m will report x86_64 and >> config.guess will then say x86_64-unknown-linux-gnu. causing major >> headaches. The easiest way to work around this is to load a uname hack >> into the kernel. making uname -m report i686 (or whatever you choose). I >> don't currently have a updated version for newer kernels handy. I'll see >> if I can dig one up / hack one together. >> >> > This is specific to sysroot and embedded? Maybe a case for > building under linux32 ? (If you don't have it, get it from e.g. > debian pool). If I've understood the problem, it's specific to > building x86 on x86_64. If I've misunderstood, please ignore this. > This affects the chroot method of trunk. Lets say your host system is x86_64-unknown-linux-gnu and CLFS_TARGET is set to i686-pc-linux-gnu. The entire build of cross-tools and tools references the CLFS_HOST and CLFS_TARGET variables. Once you chroot / boot into the final system, the target triplet is determined by the output of config.guess. see (/usr/share/automake-*/config.guess). config.guess looks at your current system and makes it's best guess on a target tripplet. It refers to uname for the machine type. If you're kernel is 64bit, uname -m will report the machine type as x86_64. Which in turn will cause config.guess to spew a 64bit target triplet.
So, when you hit the glibc build for the final system. Glibc will think it's building for x86_64-unknown-linux-gnu BUT! you build gcc to compile for i686-pc-linux-gnu. Hence the headaches I mentioned earlier. The uname hack modifies the utsname in the kernel to whatever you want it to be. so uname -m could spew i686 on a x86_64. You could even make it spew happy birthday if you wanted to, config.guess might not like that though heh. Tried my best to explain it, someone else may be able to explain it better. _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
