Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 12699 - sanity check of /lib/cpp fails during emerge system
Summary: sanity check of /lib/cpp fails during emerge system
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: Everything (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Daniel Robbins (RETIRED)
URL:
Whiteboard:
Keywords:
: gettextfail 24965 (view as bug list)
Depends on: 28630
Blocks:
  Show dependency tree
 
Reported: 2002-12-25 15:43 UTC by Zach Welch (RETIRED)
Modified: 2005-02-11 16:25 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
config.log (config.log,6.30 KB, text/plain)
2003-08-14 17:23 UTC, Stephen Becker
Details
emerge.info (emerge.info,2.59 KB, text/plain)
2005-02-09 20:24 UTC, Justin Findlay
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zach Welch (RETIRED) gentoo-dev 2002-12-25 15:43:24 UTC
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.
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-12-25 20:34:29 UTC
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?
Comment 2 Zach Welch (RETIRED) gentoo-dev 2002-12-25 23:55:12 UTC
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.
Comment 3 Daniel Robbins (RETIRED) gentoo-dev 2002-12-27 21:44:26 UTC
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.
Comment 4 Zach Welch (RETIRED) gentoo-dev 2003-02-06 18:36:50 UTC
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.
Comment 5 Colin Morey (RETIRED) gentoo-dev 2003-02-06 18:49:25 UTC
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.
Comment 6 Kyle Hutson 2003-06-13 16:04:58 UTC
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
Comment 7 SpanKY gentoo-dev 2003-07-21 14:56:40 UTC
*** Bug 24965 has been marked as a duplicate of this bug. ***
Comment 8 SpanKY gentoo-dev 2003-07-21 14:56:57 UTC
*** Bug 24438 has been marked as a duplicate of this bug. ***
Comment 9 Elmo Todurov 2003-08-06 03:58:55 UTC
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





 
Comment 10 Matthew Rickard 2003-08-08 21:29:08 UTC
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?

Comment 11 SpanKY gentoo-dev 2003-08-10 14:00:12 UTC
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
Comment 12 SpanKY gentoo-dev 2003-08-10 15:59:36 UTC
the only other thing ive seen cause this error is because linux/limits.h was not found
Comment 13 Stephen Becker 2003-08-14 17:23:45 UTC
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.
Comment 14 Thomas Weidner 2003-08-24 14:02:23 UTC
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....
Comment 15 Daniel Robbins (RETIRED) gentoo-dev 2003-09-09 15:45:36 UTC
seems like there weren't any devs patroling the release@ bugs, sorry for the delay. Assigning to seemant.
Comment 16 SpanKY gentoo-dev 2003-09-13 12:27:39 UTC
*** Bug 28630 has been marked as a duplicate of this bug. ***
Comment 17 Sven Blumenstein (RETIRED) gentoo-dev 2003-09-15 13:51:02 UTC
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.
Comment 18 Daniel Robbins (RETIRED) gentoo-dev 2003-09-16 17:35:55 UTC
Masking gettext 0.12.1. Should allow ~x86 to bootstrap.
Comment 19 Justin Findlay 2005-02-09 20:24:52 UTC
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} \
Comment 20 Justin Findlay 2005-02-09 20:28:51 UTC
I meant bug 24587. Also bug 24965.
Comment 21 Justin Findlay 2005-02-11 16:25:15 UTC
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.