I'm testing busybox with uclibc but it has ended with the following message >>> Compiling source in /var/tmp/portage/sys-apps/busybox-1.10.1-r1/work/busybox-1.10.1 ... HOSTCC scripts/basic/fixdep /bin/sh: scripts/basic/fixdep: Aucun fichier ou répertoire de ce type make[1]: *** [scripts/basic/fixdep] Erreur 1 make: *** [scripts_basic] Erreur 2 HOSTCC := $(tc-getBUILD_CC) has a strange side effect. Commenting it out makes the compilation to success again. --- /usr/portage/sys-apps/busybox/busybox-1.10.1-r1.ebuild 2008-04-27 05:40:00.000000000 +0200 +++ busybox-1.10.1-r1.ebuild 2008-04-27 19:27:35.000000000 +0200 @@ -103,8 +103,8 @@ use elibc_glibc && sed -i 's:-Wl,--gc-sections::' Makefile cat <<-EOF >> Makefile.flags CROSS_COMPILE := ${CHOST}- - HOSTCC := $(tc-getBUILD_CC) - SKIP_STRIP = y + #HOSTCC := $(tc-getBUILD_CC) + #SKIP_STRIP = y EOF # check for a busybox config before making one of our own. The command I used for the test was, PORTDIR_OVERLAY=/usr/portage/local/crossdev ROOT=/usr/src/crossdev USE="-pam savedconfig static" CHOST=x86_64-pc-linux-uclibc emerge -a1v busybox Reproducible: Always The same problem affects busybox 1.9.0 to
emerge --info, please.
translate the actual error message into english i'm guessing though that since you didnt properly set CBUILD, that is why things failed
(In reply to comment #2) > translate the actual error message into english I will be more careful about the translation next time. Promised. > > i'm guessing though that since you didnt properly set CBUILD, that is why > things failed > That's made it. Moreover I mistakenly followed all the tests with the help of ebuild install command and without cleaning the portage $WORKDIR directory. That had just led me to a wrong path because CBUILD and CHOST were never modified during the test :) Also, busybox 1.10.1 gives me more headache than ever. mdev recognizes sata drives like character devices and creates wrong devices in /dev. Thx.
that should be fixed in latest mdev ... i doubt it's a regression though, more likely your kernel changed behavior
(In reply to comment #4) > that should be fixed in latest mdev ... i doubt it's a regression though, more > likely your kernel changed behavior > I tried busybox 1.10.1-r2 and it doesn't work better. Although, I'm not sure I was using the latest mdev patch you are speaking about. Actually, it could be a regression because it is only the "mdev -s" command that is not working for sata devices. In fact, ACTION=add DEVPATH=/block/sda mdev works well and will create a block device in /dev.
(In reply to comment #4) It doesn't work better with busybox 1.10.1-r3 and a 2.6.26 kernel :( I noticed "echo mdev > /proc/sys/kernel/hotplug" setting doesn't work correctly. When set, block devices become caracter devices, although ACTION=add DEVPATH=/block/sda mdev for instance works well. As a suggestion, couldn't busybox mdev rely on DEVTYPE=disk found in /sys/devices/pci.../block/sda/uevent instead ?