I'm writing this bug to bring attention to ebuilds that compile kernel modules as part of their emerge. sys-fs/sshfs-fuse is one such example. The ppc64-32userland fails to compile such ebuilds because the 64bit compiler needs to be used for kernel modules. But since the arch is actually 'ppc', the 32bit compiler is used and thereby causes failures. One corollary is the compilation of the kernel. Typically, the CROSS variable is set in the top level Makefile in /usr/src/linux, like so: CROSS_COMPILE ?= powerpc64-unknown-linux-gnu- Given that, we have a number of ways we can deal with this problem. We could patch the top level Makefiles like I described above. We could add foo into the ebuilds to detect if uname returns ppc64 and arch is ppc, the use the 64bit compiler. And what if the ebuild had both userland and kernel components (I am not aware of such ebuilds, but they probably exist). I'm cc'ing both the ppc and ppc64 arch teams here hoping that this will start some discussion on finding an acceptable, concise way of dealing with such ebuilds. ___________________________________ emerge --info Portage 2.0.54-r2 (default-linux/ppc/ppc64/2006.0/32bit-userland/970/pmac, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15.1 ppc64) ================================================================= System uname: 2.6.15.1 ppc64 PPC970FX, altivec supported Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O3 -mtune=970 -mcpu=970 -mabi=altivec -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mtune=970 -mcpu=970 -mabi=altivec -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://tux.rchland.ibm.com/gentoo-portage" USE="ppc X alsa altivec apache2 apm arts audiofile berkdb bitmap-fonts bzip2 cdr cli cscope cups curl dri eds emboss encode esd expat fam foomaticdb fortran gcc64 gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml imlib ipv6 jpeg kde lcms ldap libg++ libwww mad mbox mhash mikmod mng motif mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre pdflib perl png python qt quicktime readline reflection samba sdl session slang spell spl ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis xml xml2 xmms xorg xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
same deal for media-sound/snd-aoa. Just adding to keep track of the ones we bump into.
snd-aoa should be merged for 2.6.18, I wouldn't worry about it too much.
Ok, I just ran into this on my G5 as well, and looking at it, I suspect it's going to be a problem for every arch/setup that uses CROSS_COMPILE or where $CC != $KERNEL_CC - my mips machine of such a case isn't running at the moment, but it will be reasonably soon. The best place to fix it is in linux-mod_src_compile, probably by making it take CROSS_COMPILE into account for $CC.
unrelated to the toolchain
Created attachment 90511 [details, diff] linux-mod-respect-KERNEL_ABI.patch Patch to apply at /usr/portage level. Modified ppc64-32ul profile and linux-mod.eclass.
the patch I've just attached solves the problem of ppc64 with 32ul being unable to compile external modules. It defines KERNEL_ABI and required parts for the ppc64/32ul profile, and modifies linux-mod.eclass to get the correct CC for compiling the modules. It needs testing in the following settings to make sure it doesn't break anything else: - pure 64-bit system - multilib system with biarch compiler (eg -m64/-m32 work) I'm trying to see if there is an easier way to get a biarch compiler instead of this hack only.
on a pure 64 bit system sys-fs/sshfs-fuse compiled fine after applying the patch.
For testcases, can you also please test: sys-block/iscsitarget-0.4.13 net-wireless/zd1211-80 Between them, that's invocation of HOSTCC/CC/LD. I haven't found an external case that uses AS or something else from binutils yet.
A couple more testcases: x11-base/x11-drm-20060608 sys-fs/cowloop-2.15-r1 sys-fs/fuse (if it's not built into your kernel)
still pure 64 bit. all of them compile fine.
Got the ok that it doesn't break AMD64, seeing if this works for Sparc now.
*** Bug 149554 has been marked as a duplicate of this bug. ***
Fixes sparc too...kernel folks please apply the first hunk of the attached patch only. Thanks.
thanks, finally johnm showed up and now I was able to commit this. Please have a look at the depend bugs now.
