While doing a regular emerge -U world, I encountered this error while emerging arts, a KDE subsystem. My guess is that it can't find the standard C++ include files for some reason; the CFLAGS might need adjusting. My standard C++ headers are all found at this path: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3 Reproducible: Always Steps to Reproduce: 1. emerge arts Actual Results: checking if Qt compiles without flags... no checking if STL implementation is SGI like... no checking if STL implementation is HP like... no configure: error: "no known STL type found - did you forget to install libstdc++-devel ?" !!! ERROR: kde-base/arts-1.1.5 failed. !!! Function kde_src_compile, Line 117, Exitcode 1 !!! died running ./configure, kde_src_compile:configure Expected Results: Installed the arts package with no errors. # emerge info Gentoo Base System version 1.4.3.10 Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.6.0-gentoo) ================================================================= System uname: 2.6.0-gentoo i686 Intel(R) Pentium(R) 4 CPU 2.80GHz ccache version 2.3 [enabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1 /share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/gen eric/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.tucdemonic.org/gentoo/ ftp://gentoo.ccccom.com http://gentoo.ccccom.com" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib apache2 apm arts avi berkdb cdr crypt cups curl dvd dvdr emacs encode esd fastcgi fbcon foomaticdb gd gdbm gif gnome gpm gtk gtk2 imap imlib java jikes jpeg kde leim libg++ libwww mad maildir mbox mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba scanner sdl slang spell sse ssl svga tcltk tcpd tetex truetype unicode usb videos x86 xface xinerama xml xml2 xmms xosd xv zlib"
Oh, I forgot to mention. I have the gcc-3.2.3-r3 installed.
Same behaviour here
i get the same error
re-emerging gcc fixes it.
Re-emerging gcc worked for me too.
I hit this same problem on some machines but not others.
Ok, closing this bug. Note that this is normally a gcc problem. (Which should be triggered by any C++ app that uses STL)
*** Bug 38869 has been marked as a duplicate of this bug. ***
gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Same error here. I'll try re-emerging gcc.
*** Bug 39024 has been marked as a duplicate of this bug. ***
Re-emerging gcc (and glibc) fixed this for me.
Could you recommend users how to avoid this bug situation in possible future builds made from-the-very-beginning?
Yes, gcc and glibc updates go hand in hand. You should always update glibc first, followed by gcc. If you do it the other way around you can create inconsistent header files, which cause problems for C++ based programs (KDE apps being the most notorious).
1) If I understood well, is it necessary every time to emerge glibc _and_only_then_ - gcc? If yes, why there is no warning about that when emerge updates the gcc or glibc separately? Or may be, it would be reasonable to do it automatically when doing such emerges? Unfortunately, the current portage tree does not handle such an "unlucky dependency". 2) Why do users have this issue when not updating but _building_ the system from the very beginning (as I had the same trouble when tried to build from the _first_ stage)? May be, my questions should be addressed not to kde maintainers team, but to gcc maintainers team? If yes, sorry for insistence, and if would not take too much efforts, please pass this note to proper addressee.
your questions are valid ones, the answer I can give you is a resounding "I don't know" :) See, gcc is the culprit that is creating the header files (see /usr/lib/gcc-lib/.../.../include/README). Obviously they are incorrectly being created. My presumption here is that they are being created by looking at headers provided by glibc, and as such if you update glibc you may get two sets of incompatible headers. This is all speculation. I don't seem to have this problem on any of my machines here locally, and others don't as well, but a lot of people *do* have the problem. My hope is that someone with the problem is able to help deduce what is causing it, and we can figure out a way to fix it. It's probably best left to the gcc people as they're the experts in this field: gcc-porting@gentoo.org
I second the sentiments of Alexey. I do _not_ consider it a reasonable solution for people experiencing problems to come search the bugs database, happen to stumble upon our walkthrough, and then use it. While eliminating the problem is the responsibility of the gcc team, portage should be doing something about it actively, even if it's only a warning message. Ideally, it should automatically re-emerge gcc after emerging glibc.
it's also looking like gcc-3.2.3-r4 has the fix for this problem in the ebuild: < # $Header: /home/cvsroot/gentoo-x86/sys-devel/gcc/gcc-3.2.3-r3.ebuild,v 1.4 2004/01/21 18:42:08 azarah Exp $ --- > # $Header: /home/cvsroot/gentoo-x86/sys-devel/gcc/gcc-3.2.3-r4.ebuild,v 1.1 2004/01/27 10:04:46 lu_zero Exp $ 100c100 < KEYWORDS="x86 ppc sparc alpha arm mips -hppa" --- > KEYWORDS="~ppc" #x86 ppc sparc alpha arm mips -hppa" 424a425,433 > # Remove generated headers, as they can cause things to break > # (ncurses, openssl, etc). > for x in `find ${WORKDIR}/build/gcc/include/ -name '*.h'` > do > if grep -q 'It has been auto-edited by fixincludes from' ${x} > then > rm -f ${x} > fi > done
Basically the only perfect way to do it is - emerge gcc (c-only is good) - emerge glibc - emerge gcc This is also what bootstrap.sh does/should do.
