i currently use multilib-portage, which does set the needed env up, then runs the usual ebuild phases and this for every requested ABI (currently only amd64 and x86). This works fine for almost all packages, which respect the env and dont place ABI-specific content e.g. into /usr/share. Now for crosscompiling from amd64 to x86, i dont need the x86 toolchain, since the amd64 multilib toolchain can handle that without issues and i do set the env to use the amd64 multilib toolchain. But the busybox ebuild does set $CROSS_COMPILE to i686-pc-linux-gnu- for ABI=x86, which results in e.g. i686-pc-linux-gnu-gcc being called, but not being installed, so the build fails. If it would just ignore $CROSS_COMPILE and respect the env, it would compile fine for both ABIs for multilib-portage. As a workaround, i have set $CROSS_COMPILE=x86_64-pc-linux-gnu- in my env, which allows me to crosscompile busybox for now, but causes issues for dev-libs/openssl
busybox sets CROSS_COMPILE to ${CHOST}- which means it'll execute ${CHOST}-gcc and such. why exactly is this a problem ? i dont understand what you're talking wrt ignoring CROSS_COMPILE -- busybox is specifically respecting the environment.
(In reply to comment #1) > busybox sets CROSS_COMPILE to ${CHOST}- which means it'll execute ${CHOST}-gcc > and such. why exactly is this a problem ? i dont understand what you're > talking wrt ignoring CROSS_COMPILE -- busybox is specifically respecting the > environment. > During crosscompiling, $CHOST is set to i686-pc-linux-gnu, but $CC and $CFLAGS contain the needed details to compile the code for x86 (same thing as in sandbox ebuild/multilib eclass), so in this case: CHOST=i686-pc-linux-gnu CC=x86_64-pc-linux-gnu-gcc CFLAGS="$CFLAGS -m32" busybox ebuild does take CHOST and sets $CROSS_COMPILE related to it and ignors the CC and CFLAGS, which are already set the right way for crosscompiling.
this has been fixed in the mean time 14 Aug 2010; Harald van Dijk <truedfx@gentoo.org> busybox-1.16.0.ebuild: Compile using CC instead of hardcoded CHOST-gcc
I just wanted to update busybox to version 1.17.4 and again got exactly the same issue, so it is still not resolved. Having a short look, the change does just tell the normal compile to use CC, but there was not change at all for crosscompilation, it still is based upon CROSS_COMPILE var and CHOST instead of just using $(tc-getCC)
i dont know what you're talking about. the ebuild clearly does: -e "/^CC/s:=.*:= $(tc-getCC):" \ -e "/^HOSTCC/s:=.*:= $(tc-getBUILD_CC):" \ and it seems to work just fine for me: CC=gcc-4.4.4 emerge busybox ... /usr/bin/gcc-4.4.4 -Wp,-MD,archival/.lzo1x_9x.o.d -std=gnu99 ... ... so you're going to have to provide real details and/or find out what's going wrong on your system
I am already talking about CROSS_COMPILE, so i really wonder, why you dont look at that part of the ebuild containing it: sed -i \ -e "/^CROSS_COMPILE/s:=.*:= ${CHOST}-:" Which results in such errors during cross-compilation: CC applets/applets.o LD applets/built-in.o LD archival/built-in.o CC archival/ar.o /bin/sh: i686-pc-linux-gnu-ar: command not found make[1]: *** [archival/built-in.o] Error 127 make[1]: *** Waiting for unfinished jobs.... CC archival/bbunzip.o LD archival/libunarchive/built-in.o /bin/sh: i686-pc-linux-gnu-ar: command not found make[1]: *** [archival/libunarchive/built-in.o] Error 127 make[1]: *** Waiting for unfinished jobs.... CC archival/libunarchive/data_align.o LD console-tools/built-in.o /bin/sh: i686-pc-linux-gnu-ar: command not found make[1]: *** [console-tools/built-in.o] Error 127 make: *** [console-tools] Error 2 make: *** Waiting for unfinished jobs.... make: *** [archival/libunarchive] Error 2 make: *** [archival] Error 2 make: *** wait: No child processes. Stop. emake failed and this is because of this part of the Makefile of busybox: CROSS_COMPILE ?= i686-pc-linux-gnu- and later, we have this block, which now works for CC, but not for the others, like ar: AS = $(CROSS_COMPILE)as CC = x86_64-pc-linux-gnu-gcc LD = $(CC) -nostdlib CPP = $(CC) -E AR = $(CROSS_COMPILE)ar NM = $(CROSS_COMPILE)nm STRIP = $(CROSS_COMPILE)strip OBJCOPY = $(CROSS_COMPILE)objcopy OBJDUMP = $(CROSS_COMPILE)objdump
why dont you actually read your summary and the error message. that error has absolutely nothing to do with CC. at no point in time did you ever state that any other tool was causing problems, nor did you post any actual error output. you cant describe issues in vague details ... you need to back them up with actual logs clearly showing the problem.
http://sources.gentoo.org/sys-apps/busybox/busybox-1.17.4.ebuild?r1=1.1&r2=1.2
