This bug probably stems from the issue reported in bug 12698. Once the bootstrap script completed successfully, I ran into a problem similar (but unlike) the previously reported /lib/cpp problems. groff, ncurses, and other packages failed their 'sanity check' of /lib/cpp. Similar problems relating to g++ were reported by other packages. On the other hand, some things compiled without complaint. I found the references to similar problems on the newgroups and Bugzilla, but none of those solutions helped. I finally gave up and ran bootstrap again; the second time through, everything seemed to be working okay. No further problems have been noted.
OK, we will need additional information, particularly info from the "config.log" of the failed builds, in order to determine and potentially fix the issue you've reported. Do you still have that failed chroot intact?
unfortunately, i 'solved' the problem with a second bootstrap... I will be re-loading another machine soon, and unless bug 12700 is fixed, I may run into the opportunity to reproduce the situation. It was a very odd set of circumstances, as I noticed the bootstrap make.conf shuffle and tried to kill the scripts in the middle of the bootstrap. I don't even know the exact failure path, but I thought it worth reporting. I expect others may run across it given bug 12698 and the fact that similar wrapper-related issues have cropped up recently. Next time, I'll remember to tar up the problematic chroot for later debugging.
OK. I'm going to close this bug as "worksforme"; if you can reproduce, then file a new bug with the new info. Right now, I don't think there's enough info to track down the original problem you experienced, so this bug report can disappear.
This bug keeps popping up. I have seen it after numerous bootstraps, and Colin just reported the same with his manual sparc bootstrap. I've got a bad image saved that was in this state, but I've done nothing with it. I've usually found it faster to do a second bootstrap, but Colin may be able to isolate the problem better.
Daniel I've got a complete snapshot of a failed bootstrap showing the same issues, although it may be slightly tainted due to scripts/bootstrap.sh failing because of a gcc-config issue, (an emerge of 1.3.1 of the same let me contiue manually), let me know what format you'd like it, or indeed if remote access would be helpful.
I am also getting this bug consistently on a stage1 LiveCD install (1.4rc4). I've searched, but can't find a 'config.log'. Let me know what you need and I'll help out as much as I can. Steps I've tried so far: - Successfully checked the MD5 sum on the ISO image - Attempted to manually emerge gcc, gcc-config, and ncurses - Changed my make.conf to older systems and repeated the last step (initally was using 'CFLAGS="-march=athlon-xp -O3 -pipe"', tried the default make.conf, and tried replacing -march... with "-mcpu=pentium") all with the same results - Attempted 'emerge portage' and 'emerge sync' then repeated - Attempted using version 1.4rc3 with same results I can be contacted at kylehutson@earthlink.net --Kyle Hutson
*** Bug 24965 has been marked as a duplicate of this bug. ***
*** Bug 24438 has been marked as a duplicate of this bug. ***
i've got the basic cd, booted from it and after some headache managed to `emerge sync`. now trying to `emerge portage` getting that damn ncurses stuff. tried to `emerge ncurses`, same. tried to `emerge gcc` - surprise surprise! it starts emerging the damned ncurses.. and i can't get my system up'n'running
I just did a new build with the 1.4 livecd of ~x86 and go this same error. It seems to pop up on bootstrap with gettext-0.12.x, but works fine with 11.5. Quite surprised to see a bug on this from 2002-12-25 :\ Seems to be lots of people on the forums running into this too. Perhaps gettext-0.12.x should be masked until this is fixed?
if you run `gcc-config 1` and try again does it work ? ive seen this pop up randomly on my box, and re-running gcc-config fixed it
the only other thing ive seen cause this error is because linux/limits.h was not found
Created attachment 16117 [details] config.log Here is a config.log from the failed gettext 0.12.1 on the newest gentoo-mips stage 1 bootstrap. I tried running "gcc-config 1" but it didn't fix the problem.
I looked a bit at the gettext source and i think the libtool m4 script included in autoconf-lib-link/aclocal.m4, because it always wants c++ (and f77?). After updating aclocal.m4 (and changing configure.ac to work with newest autoconf/automake) it SEEMS to work. i think we should wait for the next release and hope that GNU will include a better libtool version....
seems like there weren't any devs patroling the release@ bugs, sorry for the delay. Assigning to seemant.
*** Bug 28630 has been marked as a duplicate of this bug. ***
Solution for this bug: http://www.hu.linuxfromscratch.org/lfs/faq.html#cpp-fails-sanity-check GCC needs to be compiled with '--enable-languages=c,c++' to get gettext-1.12 and -1.12.1 to compile. It seems that the gcc in all stage tarballs isnt compiled with g++ support and only gets that flag on recompiling during boostrap.
Masking gettext 0.12.1. Should allow ~x86 to bootstrap.
Created attachment 50884 [details] emerge.info I have the same problem as that described in bug 2457, which in a roundabout way has been marked as a duplicate of this one, and I am at a loss at what the solution is. In the course of bootstrapping my system, sys-libs/ncurses-5.4-r5 fails to emerge as during configure the "C++ preprocessor "/lib/cpp" fails sanity check." The solution seems to be to enable c++ support for the bootstrap stage in order for ncurses to be built, but in the gcc ebuild, it seems only the C language is "enabled" for the build stage of bootstrap. sys-devel/gcc/gcc-3.2.3-r4.ebuild #... if ! use build then myconf="${myconf} --enable-shared" gcc_lang="c,c++,f77,objc" else gcc_lang="c" fi #... ${S}/configure --prefix=${LOC} \ --bindir=${BINPATH} \ --includedir=${LIBPATH}/include \ --datadir=${DATAPATH} \ --mandir=${DATAPATH}/man \ --infodir=${DATAPATH}/info \ --enable-shared \ --host=${CHOST} \ --target=${CCHOST} \ --with-system-zlib \ --enable-languages=${gcc_lang} \
I meant bug 24587. Also bug 24965.
In addition to poking around in the wrong gcc ebuild, (should have been gcc-3.3.5-r1), I've started over with stage one and the bootstrap process, which this time was successful. Therefore I cannot reproduce this error.