| Summary: | arts-1.1.5 gives "no known STL type found" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Derrick Coetzee <dc> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | djc, kutsuya, mmc, wayne |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Derrick Coetzee
2004-01-18 12:28:26 UTC
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. |
