I have a amd64 Gentoo system, which hosts a x86 uclibc chroot. My attempt to emerge klibc in the chroot failed with: scripts/kconfig/conf -s arch/x86/Kconfig CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm -> include/asm-x86 CC kernel/bounds.s kernel/bounds.c:1: error: code model 'kernel' not supported in the 32 bit mode kernel/bounds.c:1: sorry, unimplemented: 64-bit mode not compiled in make[1]: *** [kernel/bounds.s] Error 1 make: *** [prepare0] Error 2 * * ERROR: dev-libs/klibc-1.5.12-r1 failed. This seems to be caused by the fact that the default configuration for _x86_64_ was used for the kernel. Commenting out the 'unset ABI ARCH' line in the ebuild made klibc compile and install properly. This isn't of course correct in general, so I guess something like ARCH=$(tc-arch-kernel) should be done there.
ARCH=$(tc-arch-kernel) would be wrong. On a split 64-32 system (ppc64-32ul is my personal testcase), the kernel copy used by klibc MUST be configured as ppc32.
was your chroot running in linux32 or not?
(In reply to comment #2) > was your chroot running in linux32 or not? I'm not sure what you mean by "running in linux32", so I'll just describe the whole setup: host: amd64, default-linux/amd64/2007.0/desktop chroot: x86, uclibc/x86 I completely agree that the kernel used for klibc has to be configured for 32-bit mode (x86 in this case) and in fact the whole problem stems from the fact that in the case described above it isn't. By unsetting ARCH and running `make defconfig`, the kernel config system tries to configure the kernel for amd64 (host system) which is wrong, because we're in a x86 chroot.
spock: inside the chroot, what does "uname -m" return?
(In reply to comment #4) > spock: inside the chroot, what does "uname -m" return? It prints "x86_64".
Ok, your chroot should be running inside linux32/setarch then. Just doing a plain chroot is not sufficient. Consider if you run a normal x86 kernel on a x86_64 box, it does NOT say x86_64, so your chroot env shouldn't either.
