Summary: | sys-apps/busybox does not respect AR/CC/LD (relies only on CHOST) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
Component: | New packages | Assignee: | Embedded Gentoo Team <embedded> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | binki, esigra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 306835 |
Description
Thomas Sachau
2010-03-27 09:56:35 UTC
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. |