Summary: | [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu | ||
---|---|---|---|
Product: | gcc | Reporter: | Roger Hill-Cottingham <eesrjhc> |
Component: | libstdc++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | b33fc0d3, bkoz, gcc-bugs, jakub, lthode, martin.jansa, rene, wbrana |
Priority: | P3 | Keywords: | build |
Version: | 4.3.0 | ||
Target Milestone: | 4.3.0 | ||
Host: | x86_64-unknown-linux-gnu | Target: | x86_64-unknown-linux-gnu |
Build: | x86_64-unknown-linux-gnu | Known to work: | |
Known to fail: | Last reconfirmed: | ||
Attachments: | Prevent fixincludes false positive on gentoo stdio.h wrapper |
Description
Roger Hill-Cottingham
2007-02-21 15:10:56 UTC
Frankly, I have no idea what to do with this... Certainly lately we have got plenty of succesful builds on x86_64-linux and other linux platforms (just look to testresults). Something mysterious is going on during the build: bits/c++locale.h includes cstdio which then doesn't find the normal stdio.h facilities in the global namespace?!? Maybe submitter could attempt narrowing the problem somehow, for example by building snapshots older and newer... I am having the exact same problem. I've tried a few things, tried building in a stable chroot with glibc-2.4 (since my box is mainly unstable with glibc-2.5 and hashstyle) but got the exact same error. gcc-4.2 snapshots all the way to 20070305 build fine on both boxes. Does anyone have any ideas? Well Ahmed, right now you can't possibly see the exact same error, because stl_algobase.h does *not* include <iosfwd> anymore... Please provide more info. Thanks. (In reply to comment #3) > Well Ahmed, right now you can't possibly see the exact same error, because > stl_algobase.h does *not* include <iosfwd> anymore... Please provide more info. > Thanks. My error seems quite similar (with profiledbootstrap and bootstrap too). Older snapshots have the same issue. I'm using latest glibc-2.5.90.20070214. /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/./gcc/xgcc -shared-libgcc -B/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/./gcc -nostdinc++ -L/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -I/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -O2 -march=k8 -D_GNU_SOURCE -c /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc -fPIC -DPIC -o .libs/compatibility.o In file included from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:49, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string:47, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc:49: /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:100: error: '::fpos_t' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:102: error: '::clearerr' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:103: error: '::fclose' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:104: error: '::feof' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:105: error: '::ferror' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:106: error: '::fflush' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:107: error: '::fgetc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:108: error: '::fgetpos' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:109: error: '::fgets' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:110: error: '::fopen' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:111: error: '::fprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:112: error: '::fputc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:113: error: '::fputs' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:114: error: '::fread' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:115: error: '::freopen' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:116: error: '::fscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:117: error: '::fseek' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:118: error: '::fsetpos' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:119: error: '::ftell' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:120: error: '::fwrite' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:121: error: '::getc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:122: error: '::getchar' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:123: error: '::gets' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:124: error: '::perror' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:125: error: '::printf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:126: error: '::putc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:127: error: '::putchar' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:128: error: '::puts' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:129: error: '::remove' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:130: error: '::rename' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:131: error: '::rewind' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:132: error: '::scanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:133: error: '::setbuf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:134: error: '::setvbuf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:135: error: '::sprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:136: error: '::sscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:137: error: '::tmpfile' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:138: error: '::tmpnam' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:139: error: '::ungetc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:140: error: '::vfprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:141: error: '::vprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:142: error: '::vsprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:169: error: '::snprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:170: error: '::vfscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:171: error: '::vscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:172: error: '::vsnprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:173: error: '::vsscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:180: error: '__gnu_cxx::snprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:181: error: '__gnu_cxx::vfscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:182: error: '__gnu_cxx::vscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:183: error: '__gnu_cxx::vsnprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:184: error: '__gnu_cxx::vsscanf' has not been declared In file included from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string:47, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc:49: /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h: In static member function 'static typename __gnu_cxx::_Char_types<_CharT>::int_type __gnu_cxx::char_traits<_CharT>::eof()': /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:142: error: 'EOF' was not declared in this scope /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h: In static member function 'static int std::char_traits<char>::eof()': /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:294: error: 'EOF' was not declared in this scope In file included from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/iosfwd:46, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string:50, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc:49: /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++locale.h: In function 'int std::__convert_from_v(__locale_struct* const&, char*, int, const char*, ...)': /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++locale.h:94: error: 'vsnprintf' is not a member of 'std' In file included from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/fstream:783, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc:51: /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc: In constructor 'std::basic_filebuf<_CharT, _Traits>::basic_filebuf()': /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:83: error: 'BUFSIZ' was not declared in this scope make[4]: *** [compatibility.lo] Error 1 make[4]: Leaving directory `/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build' make: *** [profiledbootstrap] Error 2 (In reply to comment #4) And my toolchain: jama gcc # /lib/libc.so.6 GNU C Library 20070214 release version 2.5.90, by Roland McGrath et al. Copyright (C) 2007 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. Compiled by GNU CC version 4.2.0-alpha20070228 (prerelease) (Gentoo 4.2.0_alpha20070228). Compiled on a Linux >>2.6.20-JaMa<< system on 2007-03-05. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 1.4.1 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. jama gcc # gcc --version x86_64-pc-linux-gnu-gcc (GCC) 4.2.0-alpha20070307 (prerelease) (Gentoo 4.2.0_alpha20070307) Copyright (C) 2007 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. jama gcc # make --version GNU Make 3.81 Copyright (C) 2006 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. This program built for x86_64-pc-linux-gnu jama gcc # as --version GNU assembler 2.17.50.0.12 20070128 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-pc-linux-gnu'. > My error seems quite similar (with profiledbootstrap and bootstrap too). Older > snapshots have the same issue. Thanks, but *how much* older, exactly, we must pin-point the exact source of this problem. > I'm using latest glibc-2.5.90.20070214. Can you try with an official release. Really we need to reduce the number of independent variables, because, as far as I can see, at this point it can be anything, maybe glibc too. In the reports, on the C++ library side things don't make sense to me, frankly: <cstdio> just includes <stdio.h> and then there are the using from the global namespace. And of course nobody among the develepors is seeing the issue... I'm trying to CC Jakub as a glibc man, just in case... People encountering this kind of problem should check whether this trivial C++ snippet compiles: ///////// #include <stdio.h> #undef clearerr namespace my { using ::clearerr; } ///////// because really, in that place the build isn't doing much else... Then this snippet could be also useful, just in case we are doing something wrong in the configury (I doubt it) ////////////// #include <stdio.h> #include <bits/c++config.h> #undef clearerr _GLIBCXX_BEGIN_NAMESPACE(std) using ::clearerr; _GLIBCXX_END_NAMESPACE ////////////// Oh well, if the build really failed <bits/c++config.h> has not been installed, then include it from the exact place where is available in the build dir. In c++config we have the below lines, which I never noriced before, I wonder whether can cause problems given the our current framework (in the future is another matter...) Note hovewer, that currently __cplusplus in the official GNU tree at least is still *1*. Is it possible that only *Gentoo* GCC has an external patch defining __cplusplus as 199711L??? Paolo. // Macro used to indicate that the native "C" includes, when compiled // as "C++", have declarations in namespace std and not the global // namespace. Note, this is unrelated to possible "C" compatibility // includes that inject C90/C99 names into the global namespace. // XXX May not be necessary #if __cplusplus == 199711L # define _GLIBCXX_NAMESPACE_C 1 #endif (In reply to comment #10) > Note hovewer, that currently __cplusplus in the official GNU tree at least is > still *1*. Is it possible that only *Gentoo* GCC has an external patch > defining __cplusplus as 199711L??? But that doesn't matter, because the newly built FSF GCC still defines __cplusplus as 1 (in licpp/init.c, by the way). I'm lost... We badly need details about the behavior of the two snippets, a time-range for the appearance of the problem, anything to restrict the number of possibilities... (In reply to comment #11) Those 2 snippets working fine here and printf("%d",__cplusplus); says still "1". Ok, can we know when exactly this bootstrap problem appeared? Nobody among the developers is seeing it, I repeat, we can't reproduce it, and if the submitters are not going to help more, much more, the problem cannot be fixed, this must be clear. (In reply to comment #13) > Ok, can we know when exactly this bootstrap problem appeared? Nobody among the > developers is seeing it, I repeat, we can't reproduce it, and if the submitters > are not going to help more, much more, the problem cannot be fixed, this must > be clear. > I cannot say *how much* older, because snapshots older than about 3 weeks failed with internal error (with profiledbootstrap) and with this error http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00449.html (with bootstrap). Only last 3 weekly snapshots didn't fail until libstdc++ building. Maybe other submitters have better image when it firstly appeared, but as I said only few last weekly snapshots was trying to build libstdc++. > > I'm using latest glibc-2.5.90.20070214. I'm downgrading glibc to latest official release. > I'm trying to CC Jakub as a glibc man, just in case... Thanks anyway (In reply to comment #14) downgrading glibc didn't that trick but now() I have successfully builded latest snapshot with this "patch": --- ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio.orig 2007-03-11 20:12:59.000000000 +0100 +++ ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio 2007-03-11 20:14:00.000000000 +0100 @@ -46,7 +46,7 @@ #include <bits/c++config.h> #include <cstddef> -#include_next <stdio.h> +#include "/usr/include/gentoo-multilib/amd64/stdio.h" #ifndef _GLIBCXX_CSTDIO #define _GLIBCXX_CSTDIO 1 There is list of \*stdio\* in build directory: ./build/gcc/include-fixed/stdio.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/tr1/stdio.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/tr1/cstdio ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/stdio_sync_filebuf.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/stdio_filebuf.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/man/man3/__gnu_cxx::stdio_sync_filebuf.3 ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/man/man3/__gnu_cxx::stdio_filebuf.3 ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/cstdio.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/class____gnu__cxx_1_1stdio__filebuf.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/stdio__filebuf_8h.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/stdio_8h.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/class____gnu__cxx_1_1stdio__sync__filebuf.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/tr1_2cstdio.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/stdio__sync__filebuf_8h.xml ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/tr1/stdio.h ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/tr1/cstdio ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/ext/stdio_sync_filebuf.h ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/ext/stdio_filebuf.h ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/cstdio ./build/stage1-gcc/include-fixed/stdio.h ./build/prev-gcc/include-fixed/stdio.h ./gcc-4.3-20070309/gcc/testsuite/gcc.dg/cpp/usr/include/stdio.h ./gcc-4.3-20070309/libstdc++-v3/config/io/basic_file_stdio.cc ./gcc-4.3-20070309/libstdc++-v3/config/io/c_io_stdio.h ./gcc-4.3-20070309/libstdc++-v3/config/io/basic_file_stdio.h ./gcc-4.3-20070309/libstdc++-v3/testsuite/tr1/8_c_compatibility/cstdio ./gcc-4.3-20070309/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio ./gcc-4.3-20070309/libstdc++-v3/testsuite/27_io/headers/cstdio ./gcc-4.3-20070309/libstdc++-v3/testsuite/ext/stdio_filebuf ./gcc-4.3-20070309/libstdc++-v3/testsuite/ext/stdio_sync_filebuf ./gcc-4.3-20070309/libstdc++-v3/include/c_std/cstdio ./gcc-4.3-20070309/libstdc++-v3/include/tr1/stdio.h ./gcc-4.3-20070309/libstdc++-v3/include/tr1/cstdio ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio ./gcc-4.3-20070309/libstdc++-v3/include/ext/stdio_sync_filebuf.h ./gcc-4.3-20070309/libstdc++-v3/include/ext/stdio_filebuf.h ./gcc-4.3-20070309/libstdc++-v3/include/c_compatibility/stdio.h ./gcc-4.3-20070309/libstdc++-v3/include/c/cstdio ./gcc-4.3-20070309/fixincludes/tests/base/stdio_tag.h ./gcc-4.3-20070309/fixincludes/tests/base/stdio.h ./gcc-4.3-20070309/libssp/ssp/stdio.h I see, weird, I'm going to add Benjamin in CC, he added very recently the c_global files and I'm not familiar with #include_next... I can confirm this patch works on an amd64 gentoo sytem too. (In reply to comment #17) > I can confirm this patch works on an amd64 gentoo sytem too. And what happens if you just change that #include_next to #include <stdio.h>, that would be useful in understanding the issue and how much of it has to do with #include_next (note that, at the moment, as far as I can see, the #include_next special features are still not used) (In reply to comment #18) > (In reply to comment #17) > > I can confirm this patch works on an amd64 gentoo sytem too. > > And what happens if you just change that #include_next to #include <stdio.h>, > that would be useful in understanding the issue and how much of it has to do > with #include_next (note that, at the moment, as far as I can see, the > #include_next special features are still not used) this isn't enough even with building with this brand new gcc-4.3.0_alpha20070309. I'll repeat it with include of proper stdio.h, which looks in gentoo multilib like this jama gcc # cat /usr/include/stdio.h /* Autogenerated by create_ml_includes() in multilib.eclass */ #ifdef __i386__ # include <gentoo-multilib/x86/stdio.h> #endif /* __i386__ */ #ifdef __x86_64__ # include <gentoo-multilib/amd64/stdio.h> #endif /* __x86_64__ */ and with #include <stdio> without ".h" after that so I'll send results tomorrow (In reply to comment #19) ... > this isn't enough even with building with this brand new > gcc-4.3.0_alpha20070309. > I'll repeat it with include of proper stdio.h, which looks in gentoo multilib > like this > > jama gcc # cat /usr/include/stdio.h Ok, thanks. But then, an important question is: which (empty? not including any declaration of the expected facilities?!? What header is that?) stdio.h is instead included at build time if you don't specify explicitely the path? You should try to figure out that, whether on your system there are around (in the build directory or elsewhere) stdio.h which in fact are not the correct one. In order to do that, you could proceed as follows: go the build directory of the library and invoke by hand the same line which is failing the build of compatibility.cc, but running only the preprocessor, with -E. You save its output, it should tell us what a heck of wrong stdio.h is included. (In reply to comment #15) > ./build/gcc/include-fixed/stdio.h ... > ./build/stage1-gcc/include-fixed/stdio.h > ./build/prev-gcc/include-fixed/stdio.h Interestingly, these stdio.h do not exist on my x86_64 builds... This is a bug in the gentoo distro ask them to fix how they do multilib. (In reply to comment #22) > This is a bug in the gentoo distro ask them to fix how they do multilib. > so results are (with gcc-4.3) #include_next <stdio.h> - doesn't work #include <stdio.h> - doesn't work #include <stdio> - doesn't work #include "/usr/include/stdio.h" - works #include "/usr/include/gentoo-multilib/amd64/stdio.h" - works when /usr/include/stdio.h works then it shouldn't be distro multilib bug, should it? (In reply to comment #20) > (In reply to comment #19) > ... > > this isn't enough even with building with this brand new > > gcc-4.3.0_alpha20070309. > > I'll repeat it with include of proper stdio.h, which looks in gentoo multilib > > like this > > > > jama gcc # cat /usr/include/stdio.h > > Ok, thanks. But then, an important question is: which (empty? not including any > declaration of the expected facilities?!? What header is that?) stdio.h is > instead included at build time if you don't specify explicitely the path? You > should try to figure out that, whether on your system there are around (in the > build directory or elsewhere) stdio.h which in fact are not the correct one. > > In order to do that, you could proceed as follows: go the build directory of > the library and invoke by hand the same line which is failing the build of > compatibility.cc, but running only the preprocessor, with -E. You save its > output, it should tell us what a heck of wrong stdio.h is included. > Incidentally, I have (by using a binary search, bootstapping into an empty build directory each time) found that revision 121025 builds OK, while revision 121027 fails with this problem. Doing the suggestion above, this is what I get: roger@hertz $ /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/xgcc -sh ared-libgcc -B/MHz/roger/src/gcc-svn-121027/build-121027/./gcc -nostdinc++ -L/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/src/compatibility.cc -fPIC -DPIC -o .libs/compatibility.o -E -v Reading specs from /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/specs Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/usr/local/gcc-svn --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.3.0 20070121 (experimental) /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/cc1plus -E -quiet -nostdinc++ -v -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ -iprefix /MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/ -isystem /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include -D_GNU_SOURCE -D_GNU_SOURCE -DPIC -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include ../../../../trunk/libstdc++-v3/src/compatibility.cc -o .libs/compatibility.o -mtune=generic -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -fworking-directory -O2 ignoring nonexistent directory "/usr/local/gcc-svn/x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu /MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include /MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include /usr/local/include /usr/include End of search list. So, searching in order the directories listed above, the first occurence of stdio.h in the directory concerned is this: /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include/stdio.h which contains this: roger@hertz $ cat /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include/stdio.h /* DO NOT EDIT THIS FILE. It has been auto-edited by fixincludes from: "/usr/include/stdio.h" This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ #ifndef FIXINC_WRAP_STDIO_H_STDIO_STDARG_H #define FIXINC_WRAP_STDIO_H_STDIO_STDARG_H 1 #define __need___va_list #include <stdarg.h> /* Autogenerated by create_ml_includes() in multilib.eclass */ #ifdef __i386__ # include <gentoo-multilib/x86/stdio.h> #endif /* __i386__ */ #ifdef __x86_64__ # include <gentoo-multilib/amd64/stdio.h> #endif /* __x86_64__ */ #endif /* FIXINC_WRAP_STDIO_H_STDIO_STDARG_H */ Could this be related to the problem in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 Created attachment 14039 [details]
Prevent fixincludes false positive on gentoo stdio.h wrapper
The fixincludes script is hitting a false positive when it scans the /usr/include/stdio.h header wrapper on gentoo multilib systems. Adding a bypass for "gentoo-multilib" to the relevant fix solves this issue.
A multilib build successfully concludes with this patch.
(In reply to comment #25) > Created an attachment (id=14039) [edit] > Prevent fixincludes false positive on gentoo stdio.h wrapper Very many thanks, Steven: this has certainly done the trick. I can now bootstrap into a clean build directory and the build (of C, C++ and fortran) completes without errors. This also happens on SuSE-10.2, x86-64 Why does gentoo do this kind of crap with glibc headers? They are already multilib clean. *** Bug 34190 has been marked as a duplicate of this bug. *** *** Bug 36456 has been marked as a duplicate of this bug. *** *** Bug 37453 has been marked as a duplicate of this bug. *** For all Gentoo users who are hitting this bug: Update your GLibC to 2.7r2 or later, the new versions do not use multilib wrappers any longer. |