When trying to bootstrap from a stage1 tarball, the build of Python (2.3.4-r1) fails, complaining that the compiler cannot produce executables. The actual snippet from config.log is: configure:1545: checking for --without-gcc configure:1594: result: no configure:1600: checking for --with-cxx=<compiler> configure:1621: result: no configure:1640: checking for c++ configure:1666: result: g++ configure:1707: checking for C++ compiler default output configure:1710: g++ -O2 -mcpu=i686 -fomit-frame-pointer conftest.cc >&5 ./configure: line 1: g++: command not found I cannot bootstrap the system. A workaround would seem to be to use a stage2 tarball instead. I have not yet tested this. Reproducible: Always Steps to Reproduce: 1. Boot system. Start install process. 2. Install stage1 tarball. 3. Run /usr/portage/scripts/bootstrap.sh. Wait. Actual Results: The bootstrap process, having failed, stopped. Expected Results: Should not be looking for g++, and compiled. Specifically, I've booted from the SELinux LiveCD (the latest I could find, 20040616), and followed the install docs as per the website. emerge info says: livecd portage # emerge info Portage 2.0.51-r3 (selinux/2004.1/x86, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.5-gentoo-r1 i686) ================================================================= System uname: 2.6.5-gentoo-r1 i686 VIA Nehemiah Gentoo Base System version 1.4.16 Autoconf: Automake: Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r2 Libtools: ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://adelie.polymtl.ca/ ftp://cs.ubishops.ca/pub/gentoo ftp://gentoo.risq.qc.ca/ ftp://gentoo.agsn.ca/ http://gentoo.mirrored.ca/ ftp://gentoo.mirrored.ca/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage" USE="apache2 berkdb crypt gd mysql ncurses nptl pam perl php python readline sasl selinux ssl tcpd usb x86 zlib" Again, a workaround seems to be to use a stage2 tarball. I have not yet tested this.
As per conversation in IRC, I added "--with-cxx=no" to the econf section of the Python 2.3.4-r1 ebuild. It now fails telling me that '"/lib/cpp" fails sanity check'. config.log complains a few times about: /usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory once about: conftest.c:2: error: syntax error before "me" configure:2619: $? = 1 configure: failed program was: | #ifndef __cplusplus | choke me | #endif and a few times about: /usr/include/sys/cdefs.h:31: #error "You need a ISO C conforming compiler to use the glibc headers" When I try to run /lib/cpp directly: livecd lib # /lib/cpp Could not run/locate "cpp" livecd lib # Note that this is all from within the chroot. If I run /lib/cpp from outside the chroot, it seems to operate just fine.
Left the versions of everyone out in the initial bug report: LiveCD: 20040616-1 Stage1: 20041123 Portage: 20050306
this really cant be solved without more info cpp and linux headers both exist in stage1 ... what you've shown is that for some reason they no longer existed on your machine
