dhcp-3.0.1 breaks just at the first invocation of gcc: Making all in common make[2]: Entering directory `/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/work.linux-2.2/common' i686-pc-linux-gnu-gcc -g -I/var/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1 -I/var/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/includes -DLINUX_MAJOR=2 -DLINUX_MINOR=6 -DPARANOIA -DEARLY_CHROOT -mtune=athlon-tbird -O2 -fomit-frame-pointer -pipe -c -o raw.o raw.c In file included from raw.c:53: /var/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/includes/dhcpd.h:309: error: mode `byte' applied to inappropriate type /var/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/includes/dhcpd.h:310: error: mode `byte' applied to inappropriate type /var/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/includes/dhcpd.h:311: error: mode `byte' applied to inappropriate type make[2]: *** [raw.o] Error 1 make[2]: Leaving directory `/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/work.linux-2.2/common' make[1]: *** [all] Error 1 make[1]: Leaving directory `/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/work.linux-2.2' make: *** [all] Error 2 this is a fairly fresh gentoo setup, details below. what i noticed is the following output at the beginning: >>> Unpacking dhcp-3.0.1.tar.gz to /var/tmp/portage/dhcp-3.0.1/work * Applying dhcp-3.0+paranoia.patch ... [ ok ] * Applying dhcp-3.0pl2-fix-perms.patch ... [ ok ] >>> Source unpacked. System Type: linux-2.2 make[1]: Entering directory `/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/work.linux-2.2' Making links in common make[2]: Entering directory `/tmp/portage/dhcp-3.0.1/work/dhcp-3.0.1/work.linux-2.2/common' this is no linux-2.2 system as you can see. is this normal or are the detection routines failing? Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r2 (default-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20041021-r0, 2.6.8-gentoo-r3 i686) ================================================================= System uname: 2.6.8-gentoo-r3 i686 AMD Athlon(tm) processor Gentoo Base System version 1.6.4 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-mtune=athlon-tbird -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=athlon-tbird -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow aalib acl acpi apache2 apm berkdb bzlib crypt cups curl dba dedicated encode ethereal fam fastcgi foomaticdb ftp gd gif icq imagemagick imap imlib ipv6 jpeg libwww lm_sensors maildir mailwrapper mime mmx mysql ncurses nls nocd nptl odbc pam pcre perl php png pnp ppds python qmail readline rrdtool samba session slang snmp soap sockets spamassassin spell ssl svg tcpd threads tidy tiff truetype unicode usb vhosts wmf xml xml2 zlib"
setting the gcc-profile to i686-pc-linux-gnu-3.3.4 worked. dhcp-3.0.1 compiled fine with gcc-3.3.4-r1.
ditto on x86_64. can we upstream this for attention?
same here... but here someone has compiled it with gcc 3.4.2: http://rpmfind.net/linux/RPM/PLD/dists/ac/ready/i586/dhcp-3.0.1-2.i586.html can't find the used patches
It's a gcc bug: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00150.html can someone forward this to the gcc ebuild people?
this is -not- a bug in gcc. rather, a bug in gcc was fixed... revealing this bug in dhcp: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18282#c2
bam! fixed in cvs. dhcp should now compile with gcc 3.4 again. :) give it 15-30 minutes to reach rsync. sorry it took so long to fix this one ^^;
