Bug 232269 – merge of klibc-1.5.12-r1 in a x86 chroot on amd64 fails

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Michal Januszewski (RETIRED) 2008-07-18 22:33:49 UTC]

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.

[Comment 1 Robin Johnson 2008-07-19 03:40:56 UTC]

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.

[Comment 2 Robin Johnson 2008-07-19 03:41:25 UTC]

was your chroot running in linux32 or not?

[Comment 3 Michal Januszewski (RETIRED) 2008-07-19 10:51:15 UTC]

(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.

[Comment 4 Robin Johnson 2008-07-19 16:50:58 UTC]

spock: inside the chroot, what does "uname -m" return?

[Comment 5 Michal Januszewski (RETIRED) 2008-07-19 18:17:08 UTC]

(In reply to comment #4)
> spock: inside the chroot, what does "uname -m" return?

It prints "x86_64".
 

[Comment 6 Robin Johnson 2008-07-19 18:41:02 UTC]

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.