I did a stage 3, and I when I emerge -e world, it stops on python-fchksum-1.7.1. creating build creating build/temp.linux-i686-2.3 i386-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -Os -mcpu=i586 -fomit-frame-pointer -mmmx -fPIC -I/usr/include/python2.3 -c md5.c -o build/temp.linux-i686-2.3/md5.o gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc" error: command 'i386-pc-linux-gnu-gcc' failed with exit status 1 This was a generic stage3, and I have set CHOST to i586-pc-linux-gnu. gcc-config -l shows i586-pc-linux-gnu-3.3.5-20050130 being used, there are no i386 versions listed. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.9-gentoo-r13NEW i686) ================================================================= System uname: 2.6.9-gentoo-r13NEW i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 10 2005, 20:47:05)] dev-lang/python: 2.3.4-r1 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-Os -mcpu=i586 -fomit-frame-pointer -mmmx" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -mcpu=i586 -fomit-frame-pointer -mmmx" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig distlocks nodoc noman sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="avi crypt gtk2 jpeg mmx pam png readline spell ssl tcpd usb userlocales wifi x86 userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Someone on IRC told me to emerge python first, this fixed the problem. I would also like to mention that there are some weird dependency issues here, and this could be an issue for other people who install with stage3/rebuild. I think the problem is that python-fchksum doesn't depend on python.
Do not set CHOST if doing stage 2/3 install - see comments in make.conf.example and handbook. # Host Setting # ============ # # DO NOT CHANGE THIS SETTING UNLESS YOU ARE USING STAGE1! # Change this line as appropriate (i686, i586, i486 or i386). # All modern systems (even Athlons) should use "i686-pc-linux-gnu". # All K6's are i586.
AFAICT this is a problem for stage1 installs also. In "emerge -e system" it tries to merge python-fchksum before python. Since the stage1 python is compiled for the generic CHOST it results in this error. A simple fix would be to add DEPEND="dev-lang/python" so that python is always built before python-fchksum. Many people have encountered this problem: http://forums.gentoo.org/viewtopic-t-314985-start-401.html http://dev.gentoo.org/~citizen428/hypermail/gentoo-catalyst/0504/0311.html
I tried adding DEPEND="dev-lang/python" in my overlay but apparently portage doesn't care about that during "emerge -e system". It seems that the i386-pc-linux-gnu-gcc comes from the CC variable in /usr/lib/python2.3/config/Makefile and a user has reported success after only editing that file: http://forums.gentoo.org/viewtopic-p-2260623.html#2260623 Another possible solution would be to remerge python within /usr/portage/scripts/bootstrap.sh
It seems like either the distutils or python eclass would be a natural place to implement a fix for this. It could check the CHOST in make.conf and automatically edit the Makefile if necessary.
I finally realized that this bug is a duplicate :-) http://bugs.gentoo.org/show_bug.cgi?id=88777
Reopen...
... to resolve properly. *** This bug has been marked as a duplicate of 88777 ***
