After unpacking the portage-2002-8-5.tar.bz2 snapshot (my firewall doesn't work with gentoo so I cannot use rsync) and changing make.conf to reflect 686, and setting GENTOO_MIRRORS to a local machine (which I have downloaded all needed files) I do a scripts/bootstrap.sh During the python build, I get an error that there is no c++ compiler. Guess what there isn't one! I am going to try stage2 and see how that goes. cheers
root@rux0r root # grep rsync /etc/services rsync 873/tcp # rsync rsync 873/udp # rsync my best guess is to enable those ports on your firewall
Did bootstrap.sh complete successfully? Maybe you did something like "scripts/bootstrap.sh ; emerge system" ?
Bootstrap.sh was where the problem occured, during the merge of portage 2.0.25 One of the dependant packages required c++ which is not on the stage1 tarball. I verified this by trying to compile test.cpp and got an error saying that there was no c++ compiler on the system. After putting stage2 on the same machine, I am slowly working my way through an emerge system.
I've got the same error. Here the last couple of lines from an 'scripts/bootstrap': >>> Regenerating /etc/ld.so.cache... >>> sys-devel/libtool-1.4.1-r9 merged. >>> emerge sys-apps/groff-1.17.2-r2 to / >>> Downloading http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/groff-1.17.2.tar.gz --16:45:27-- http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/groff-1.17.2.tar.gz => `/usr/portage/distfiles/groff-1.17.2.tar.gz' Resolving www.ibiblio.org... done. Connecting to www.ibiblio.org[152.2.210.81]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,503,169 [application/x-tar] 100%[=====================================================================================>] 1,503,169 85.05K/s ETA 00:00 16:45:44 (85.05 KB/s) - `/usr/portage/distfiles/groff-1.17.2.tar.gz' saved [1503169/1503169] >>> md5 ;-) groff-1.17.2.tar.gz >>> Unpacking source... >>> Unpacking groff-1.17.2.tar.gz patching file doc/Makefile patching file doc/groff.texinfo >>> Source unpacked. configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for i686-pc-linux-gnu-g++... g++ checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking that C++ compiler can compile simple program... no configure: error: a working C++ compiler is required !!! ERROR: The ebuild did not complete successfully. !!! Function src_compile, Line 7, Exitcode 1 !!! (no error message) !!! emerge aborting on /usr/portage/sys-apps/groff/groff-1.17.2-r2.ebuild . So what happend: groff's configure script failed because of a missing g++ (I checked this in groff's config.log). This is not unexpected because gcc is not yet emerged. groff itself gets emerged during bootstrapping because binutils depends on it. But this happens before gcc gets energed. So I think a fix is either emerge gcc before bootstrapping or add g++ to the stage1 tarball. Cheers, Andreas
Adding c++ to the tarball sounds like the fix, but if that would make it too large then I guess your second suggestion to put the gcc build before groff is really the only other choice.
If it complains there is no c++ for the bootstrap there is a different problem, it is not honoring USE="-* bootstrap build", there should be no c++ at that point inthe game and python should honor that. try putting the USE stuff inline with the emerge call(s) in bootstrap.sh (look at script for details), i.e. USE="-* build bootstrap" emerge $myGLIBC ..... (double check that is proper USE as defined earlier in the script)
I bootstrapped 1.4_beta in chroots on my installed system from stage1 upwards at mostly least 10 times with different CHOST/march/mcpu settings. None of my bootstraps has died this way.
I recently tryed a new build, with the portage-20020819.tar.bz2 snapshot, containing the 2.0.28 version of portage. The problem has diapeared.
