As Brent requested here's the "tracker" bug for all stuff that needs to be fixed in the klibc-1.5 ebuild. For now I added a rather small hack to get the it building on ppc/ppc64 (at least I hope).
This still does not work. I'm bumping into this while trying to compile ppc kernels for the upcoming release. I have temporarily removed the splash package from the spec so I can keep building (splash brings in klibc as a dep). * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 2.6.22-gentoo-r5-ppc32 * CTARGET = powerpc-unknown-linux-gnu * Applying klibc-1.4.11-interp-flags.patch ... [ ok ] * Applying klibc-1.4.13-types.h.patch ... [ ok ] * Applying klibc-1.4.13-resumelib.patch ... [ ok ] * Applying klibc-1.4.9-mips32.patch ... [ ok ] GEN klcc/klibc.config HOSTCC scripts/basic/fixdep GEN klcc/klcc KLIBCCC usr/klibc/__static_init.o KLIBCCC usr/klibc/vsnprintf.o KLIBCCC usr/klibc/snprintf.o KLIBCCC usr/klibc/vsprintf.o KLIBCCC usr/klibc/sprintf.o KLIBCCC usr/klibc/asprintf.o usr/klibc/vsnprintf.c:1: error: -m64 not supported in this configuration usr/klibc/snprintf.c:1: error: -m64 not supported in this configuration make[2]: *** [usr/klibc/vsnprintf.o] Error 1 make[2]: *** Waiting for unfinished jobs.... usr/klibc/sprintf.c:1: error: -m64 not supported in this configuration make[2]: *** [usr/klibc/snprintf.o] Error 1 usr/klibc/vsprintf.c:1: error: -m64 not supported in this configuration usr/klibc/__static_init.c:1: error: -m64 not supported in this configuration make[2]: *** [usr/klibc/sprintf.o] Error 1 usr/klibc/asprintf.c:1: error: -m64 not supported in this configuration make[2]: *** [usr/klibc/__static_init.o] Error 1 make[2]: *** [usr/klibc/vsprintf.o] Error 1 make[2]: *** [usr/klibc/asprintf.o] Error 1 make[1]: *** [all] Error 2 make: *** [klibc] Error 2 * * ERROR: dev-libs/klibc-1.4.13 failed.
Phreak, Okay here is the deal. For ppc64 32bit userlands, some packages would consider this a cross_compile environment because the kernel is 64 and the userland is 32bit. I notice mips has similar foo in there. if ! use n32; then epatch "${FILESDIR}"/${PN}-1.4.9-mips32.patch fi I didn't look at that patch. But I do have a solution. It's up to you on how you want to handle it and hopefully without sticking it to the other archs. The ebuild foo you added the last go-around is almost working. The one exception is the ARCH variable in src_compile(). Let's look at the problem area: ... if is_cross ; then einfo "ARCH = \"$(guess_arch)\"" einfo "CROSS = \"${CTARGET}-\"" emake ARCH=$(guess_arch) \ CROSS="${CTARGET}-" \ EXTRA_KLIBCAFLAGS="-Wa,--noexecstack" \ EXTRA_KLIBCLDFLAGS="-z,noexecstack" \ libdir="/usr/$(get_libdir)" \ SHLIBDIR="/$(get_libdir)" \ mandir="/usr/share/man" \ INSTALLDIR="/usr/$(get_libdir)/klibc" \ ${myargs} || die "Compile failed!" else env -u ARCH \ emake \ EXTRA_KLIBCAFLAGS="-Wa,--noexecstack" \ EXTRA_KLIBCLDFLAGS="-z,noexecstack" \ libdir="/usr/$(get_libdir)" \ SHLIBDIR="/$(get_libdir)" \ ... The ppc64 32bit userland goes through the second clause (this else i.e. not_cross). It looks like ARCH variable is cleared there (did I read that right? My bash foo is weak). So I think that leaves ARCH detection up to klibc which simply looks at the kernel arch to determine that variable. If I do something as simple as injecting ARCH=$(guess_arch) into the second clause, klibc compiles fine. I didn't try an install but it compiles. So to me you have two, probably more, solutions: 1. Force ppc64 32bit UL through the is_cross clause. 2. If ppc63 32ul, pass ARCH=$(guess_arch) or something similar. I'll be around if you want to talk tomorrow. I should have time to test. We should be able to knock this out.
This looks very similar to building kernel modules on the mixed-length arches (64-bit kernel, 32-bit ul). Look at linux-mod_src_compile, I think you can remove a lot of duplicated work that was already done, because both the kernel and klibc use the Kbuild system. guess_arch - this function is identical in purpose to tc-arch-kernel. Additionally, instead of setting CROSS_COMPILE="${CTARGET}-" that implicitly defines $CC, linux-mod explicitly sets $HOSTCC and $CC, using the multilib variables in your profile. This is an untested bit below (I don't have time to test it right now, and my G5 is down), but it should work to replace the entire "if tc-is-cross-compiler ; then ... else ... fi" block. ===== local myARCH="${ARCH}" myABI="${ABI}" ARCH="$(tc-arch-kernel)" ABI="${KERNEL_ABI}" emake KLIBCARCH="${ARCH}" \ HOSTCC="$(tc-getBUILD_CC)" CC="$(get-KERNEL_CC)" \ LDFLAGS="$(get_abi_LDFLAGS)" \ EXTRA_KLIBCAFLAGS="-Wa,--noexecstack" \ ... ${myargs} || die "Compile failed!" ARCH="${myARCH}" ABI="${myABI}" =====
Ok, using phreak's initial work, I do have it building on ppc64-32ul now. According to the sources, you should build it to target the userspace for your system, not the kernel. Now, here is where it gets tricky. It needs a copy of the kernel sources, configured for your target! For PPC, this is not an issue, as there is the unified include/asm-powerpc directory, but for sparc64-32ul, this causes a problem. The system copy should be configured as include/asm-sparc64, which means it cannot be used. This would also effect amd64-32ul, which I don't believe we officially support, as well as sh64-32ul, which again is not supported. Regardless, using the system sources for headers rubs me the wrong way. I KNOW I've got boxes where my kernel hacking would cause it to break, when I want it to generate a stable klibc and not use my system sources. I'm going to try to see if I can make a variant that uses the distfiles from sys-kernel/linux-headers instead.
I have commited 1.5.7 to the tree with the fixups for this. There is going to be an -r1 shortly, that fixes the other bugs filed against klibc (I want those changes in a separate ebuild).
I fixed the other bugs now. For the reference, I tested on the following: Portage 2.1.3.19 (default-linux/amd64/2006.1, gcc-4.1.2, glibc-2.7-r0, 2.6.24-rc1-pmp-gc1698780 x86_64) Portage 2.1.3.19 (default-linux/ppc/ppc64/2007.1/32bit-userland/desktop/970/pmac, gcc-4.2.2, glibc-2.6.1-r0, 2.6.23-gentoo-r1-prod ppc64) Portage 2.1.3.19 (default-linux/x86/2006.1/desktop, gcc-4.2.2, glibc-2.7-r0, 2.6.24-rc2-g91b2b1a4 i686)
