User account creation filtered due to spam.

Bug 40974 - [4.9/5/6/7 Regression] cannot build gcc-4.4.1: fenv_t has not been declared
Summary: [4.9/5/6/7 Regression] cannot build gcc-4.4.1: fenv_t has not been declared
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.4.1
: P4 normal
Target Milestone: 4.9.4
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on:
Blocks:
 
Reported: 2009-08-05 16:44 UTC by booleandomain
Modified: 2016-07-31 10:08 UTC (History)
13 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-cross-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-08-10 22:00:24


Attachments
x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h (870 bytes, text/plain)
2009-08-07 11:58 UTC, booleandomain
Details
x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h (651 bytes, text/plain)
2009-08-07 12:00 UTC, booleandomain
Details
build-stage1 (714 bytes, text/plain)
2009-08-07 12:03 UTC, booleandomain
Details
patch to turn off multiple inclusion guard for fenv.h C++ wrapper (340 bytes, patch)
2009-12-22 21:04 UTC, Ralf Wildenhues
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description booleandomain 2009-08-05 16:44:31 UTC
I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1 for the target system. make fails with the following error message:

make[2]: Entering directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/mnt/clfs/cross-tools/usr/bin/x86_64-unknown-linux-gnu-gcc " "CFLAGS=-g -O2 -march=core2  " "CXXFLAGS=-g -O2   -D_GNU_SOURCE  " "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-g -O2 -march=core2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2 -march=core2  " "LIBCFLAGS_FOR_TARGET=-g -O2 -march=core2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr" "infodir=/usr/info" "libdir=/usr/lib" "includedir=/usr/include" "prefix=/usr" "tooldir=/usr/x86_64-unknown-linux-gnu" "gxx_include_dir=/usr/include/c++/4.4.1" "AR=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/ar" "AS=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/as" "LD=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/ld" "RANLIB=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/ranlib" "NM=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/nm" "DESTDIR=" "WERROR=" all-recursive
make[3]: Entering directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'
Making all in include
make[4]: Entering directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include'
mkdir -p ./x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch
/mnt/clfs/cross-tools/usr/bin/x86_64-unknown-linux-gnu-c++  -x c++-header -g -O2   -D_GNU_SOURCE   -I/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/libsupc++ -O2 -g /mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/include/precompiled/stdtr1c++.h -o x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
In file included from /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/cfenv:46,
                 from /mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/include/precompiled/stdtr1c++.h:33:
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:49: error: '::fenv_t' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:50: error: '::fexcept_t' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:53: error: '::feclearexcept' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:54: error: '::fegetexceptflag' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:55: error: '::feraiseexcept' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:56: error: '::fesetexceptflag' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:57: error: '::fetestexcept' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:59: error: '::fegetround' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:60: error: '::fesetround' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:62: error: '::fegetenv' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:63: error: '::feholdexcept' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:64: error: '::fesetenv' has not been declared
/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:65: error: '::feupdateenv' has not been declared
make[4]: *** [x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch] Error 1
make[4]: Leaving directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/mnt/clfs/sources/gcc-build'
make: *** [all] Error 2

The configure command contained the following options: --prefix=/usr --build=x86_64-cross-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --enable-languages=c,c++ --disable-multilib

The following environment variables were set before the build started:

export CC=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-gcc
export CXX=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-c++
export AR=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ar
export AS=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-as
export LD=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ld
export NM=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-nm
export OBJDUMP=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-objdump
export RANLIB=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ranlib
export STRIP=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-strip
export CC_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-gcc
export CXX_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-c++
export AR_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ar
export AS_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-as
export LD_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ld
export NM_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-nm
export OBJDUMP_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-objdump
export RANLIB_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ranlib
export STRIP_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-strip

CLFS_CROSS_TOOLS is the path to the gcc cross-compiler. CLFS_TARGET is x86_64-unknown-linux-gnu.
Comment 1 Paolo Carlini 2009-08-05 22:26:04 UTC
You should try to figure out the reason of those errors: whether, for some reason, _GLIBCXX_HAVE_FENV_H is undefined, thus <fenv.h> is not included in tr1/cfenv. Or, the configure test for the facilities in <fenv.h> (generated from acinclude.m4) wrongly defines _GLIBCXX_USE_C99_FENV_TR1. All in all, the issue is very mysterious to me, on x86_64-linux, in any case, <fenv.h> should be perfectly fine. I suspect you are doing something wrong in the setup for cross-compilation. I must also say, not being an expert of cross-compilation, I have no idea what are you trying to do, why you actually need a cross-compiler, if you are targeting your same machine...
Comment 2 booleandomain 2009-08-06 19:21:53 UTC
My goal is to build a GNU/Linux system similar to CLFS (cross-lfs.org), where the host and the target are the same physical machine.

I'm not an expert, but anyway it seems that the C++ cross-compiler is trying to build the stdtr1c++.h header, which asks for tr1/cfenv. tr1/cfenv asks for bits/c++config.h (that defines _GLIBCXX_HAVE_FENV_H 1 and _GLIBC_USE_C99_FENV_TR1 1), then it asks for fenv.h and finally it asks for tr1_impl/cfenv. Since _GLIBCXX_USE_C99_FENV_TR1 is set to 1, tr1_impl/cfenv uses fenv_t and (don't know why) it fails.

The fenv.h file in gcc build directory is only 71 bytes long, while the fenv.h provided by glibc is 4670 bytes long (don't know if this is ok).

I'm not a C++ expert, so I don't know what fenv_t neither where to look for it.

I also tried to --disable-c99 for both the cross-compiler and the target compiler, but the problem is still there.
Comment 3 booleandomain 2009-08-06 20:20:53 UTC
I added the --disable-libstdcxx-pch option to the configure command for the target gcc compiler, and now make works. Now I'm no longer sure if this is a bug or my fault...
Comment 4 Paolo Carlini 2009-08-07 08:22:26 UTC
Nice that we have a workaround, still, the problem should not happen anyway: in normal builds on x86_64-linux, no fenv.h is generated during the build and the one provided by the underlying libc is of course fine. For some reason, for the build of the PCHs the wrong one is picked. Still, a cross with host == target seems very unusual to me, and it's the first time I hear of cross-lfs, it may well be possible that the build system is not completely ready for such kind of setup. Or it requires special configuration options. I'm adding people more knowledgeable than me of configure issues in CC (maybe my friend Paolo, in particular, can help picking the best person?!?)
Comment 5 Paolo Bonzini 2009-08-07 09:46:46 UTC
No, the build system should support everything; not just host==target != build which is not so uncommon -- for example this is how cygwin worked before it could host GCC -- but even the admittedly crazy target==build != host.

Then of course some configurations are less tested.  I'll look at the bug if I have time, but IIUC it's likely a problem somewhere in the driver?
Comment 6 Paolo Carlini 2009-08-07 10:12:36 UTC
Paolo, if you could help, it would be great. About the driver, really I have no idea. And I have never seen that almost-empty generated fenv.h, if it's really happening maybe the library-proper isn't at fault...
Comment 7 Paolo Bonzini 2009-08-07 10:45:19 UTC
What's the content of gcc/fenv.h in the build directory?  If I have to guess, I'd suppose it's generated by fixincludes.
Comment 8 booleandomain 2009-08-07 11:58:13 UTC
Created attachment 18316 [details]
x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h
Comment 9 booleandomain 2009-08-07 12:00:30 UTC
Created attachment 18317 [details]
x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h
Comment 10 booleandomain 2009-08-07 12:03:20 UTC
Created attachment 18318 [details]
build-stage1
Comment 11 booleandomain 2009-08-07 12:10:00 UTC
There is no gcc/fenv.h in the build directory. I attached the only fenv.h files I could find in it. I attached the script I use for building the cross-toolchain, too. I slightly modified the build process: I removed environment variables such as CC and LD, and I added the path to the cross-tools binaries in PATH. I previously said fenv.h was 71 bytes long because of "du" command, but gcc bugzilla says something very different. Probably I have to learn how to properly use "du"...
Comment 12 Andrew Pinski 2009-09-26 19:44:28 UTC
fenv.h should come from glibc ...
Comment 13 armand.potter 2009-12-15 20:48:35 UTC
I'm using about the same configuration (cross-LFS build but with gcc 4.4.2) and got the same error. I did some investigations and the problem is that fenv.h file from build tree is first included (and defines _GLIBCXX_FENV_H to 1) and then include_next includes fenv.h from host (installed in /usr/TARGET/include/c++/VERSION/fenv.h) and this time as _GLIBCXX_FENV_H is already defined, does nothing so fenv.h from glibc is never included.

For a native build, just compiled c++ compiler is used with the -nostdinc++ flag so that /usr/TARGET/include/c++/VERSION/fenv.h is not seen and include_next works as expected including glibc header.

I don't know what is the correct solution but at least you know what the real problem is. 
~                                                                                            
Comment 14 Paolo Carlini 2009-12-16 16:17:54 UTC
Paolo, Ralf, I'd like to resolve this one for 4.5.0. Any idea?
Comment 15 Paolo Bonzini 2009-12-16 17:30:39 UTC
Well, the solution could be disable PCH by default. :-)  Is anybody using it?...
Comment 16 Paolo Carlini 2009-12-16 19:15:43 UTC
Well, for sure the testsuite runs much faster. Anyway, if we can't really figure out a proper fix, maybe we can disable PCHs when we are building cross-compilers.
Comment 17 Ralf Wildenhues 2009-12-16 21:51:52 UTC
Armand, to expand on comment #13, could you post the exact command and error message you're getting, as the original poster did?

Both of you, could you cd to the directory where the failure occurs, remove the -o ARG from the command, add -E and pipe it into 'grep -i fenv' and post the result, so we can see for sure which headers are being picked up?  Something like this:

/mnt/clfs/cross-tools/usr/bin/x86_64-unknown-linux-gnu-c++  -x c++-header -g
-O2   -D_GNU_SOURCE  
-I/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/libsupc++ -O2 -g
/mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/include/precompiled/stdtr1c++.h -E | grep -i fenv

libstdc++-v3/acinclude.m4 has this code:

  # For Canadian crosses, pick this up too.
  if test $CANADIAN = yes; then
    GLIBCXX_INCLUDES="$GLIBCXX_INCLUDES -I\${includedir}"
  fi

but it is not enabled in this case because $build = $target.

Thanks.
Comment 18 armand.potter 2009-12-19 15:44:21 UTC
Configure is as follow:

/tmp/gcc-4.4.2/configure --enable-shared --enable-clocale=gnu --enable-__cxa_atexit --libexecdir=/usr/lib --enable-threads=posix --enable-languages=c,c++ --build=i686-pc-linux-gnu --host=x86_64-mine-linux-gnu
--target=x86_64-mine-linux-gnu

Here is the error:
make[2]: Entering directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=x86_64-mine-linux-gnu-gcc " "CFLAGS=-g -O2 -pipe -march=athlon64  " "CXXFLAGS=-O2 -pipe -march=athlon64   -D_GNU_SOUR
CE  " "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-g -O2 -pipe -march=athlon64" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/b
in/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2 -pipe -march=athlon64  " "LIBCFLAGS_FOR_TARGET=-g -O2 -pipe -march=athlon64" "MAKE=make" 
"MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr" "infodir=/usr/share/inf
o" "libdir=/usr/lib" "includedir=/usr/include" "prefix=/usr" "tooldir=/usr/x86_64-mine-linux-gnu" "gxx_include_dir=/usr/include/c++/4.4.2" "AR=/usr/lib/gcc/x86_64-mine-li
nux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/ar" "AS=/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/as" "LD=/usr/lib/gcc/x86_64-min
e-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/ld" "RANLIB=/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/ranlib" "NM=/usr/lib/gc
c/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-li
nux-gnu/bin/nm" "DESTDIR=" "WERROR=" all-recursive
make[3]: Entering directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3'
Making all in include
make[4]: Entering directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include'
mkdir -p ./x86_64-mine-linux-gnu/bits/stdtr1c++.h.gch
x86_64-mine-linux-gnu-c++  -x c++-header -O2 -pipe -march=athlon64   -D_GNU_SOURCE   -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/x86_64-mine-linux-gnu -I/
tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.4.2/libstdc++-v3/libsupc++ -O2 -g /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h -o x86
_64-mine-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
In file included from /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv:46,
                 from /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h:33:
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:49: error: '::fenv_t' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:50: error: '::fexcept_t' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:53: error: '::feclearexcept' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:54: error: '::fegetexceptflag' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:55: error: '::feraiseexcept' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:56: error: '::fesetexceptflag' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:57: error: '::fetestexcept' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:59: error: '::fegetround' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:60: error: '::fesetround' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:62: error: '::fegetenv' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:63: error: '::feholdexcept' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:64: error: '::fesetenv' has not been declared
/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:65: error: '::feupdateenv' has not been declared
make[4]: *** [x86_64-mine-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch] Error 1
make[4]: Leaving directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/tmp/gcc-build'
make: *** [all] Error 2

And with -E | grep -i fenv:
subway:/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include$ x86_64-mine-linux-gnu-c++  -x c++-header -O2 -pipe -march=athlon64   -D_GNU_SOURCE   -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/x86_64-mine-linux-gnu -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.4.2/libstdc++-v3/libsupc++ -O2 -g /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h -E | grep -i fenv
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 1
# 32 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv"
# 33 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 3
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 1 3
# 32 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 3
# 33 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 3
# 1 "/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/include/c++/4.4.2/fenv.h" 1 3
# 37 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 2 3
# 37 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 2 3
# 46 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 3
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv" 1 3
# 44 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv" 3
  using ::fenv_t;
# 47 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 2 3

And with -nostdinc++ added (compilation runs ok):
subway:/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include$ x86_64-mine-linux-gnu-c++ -nostdinc++ -x c++-header -O2 -pipe -march=athlon64   -D_GNU_SOURCE   -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/x86_64-mine-linux-gnu -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.4.2/libstdc++-v3/libsupc++ -O2 -g /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h -E | grep -i fenv
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 1
# 32 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv"
# 33 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 3
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 1 3
# 32 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 3
# 33 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 3
# 1 "/new-system/usr/include/fenv.h" 1 3 4
# 58 "/new-system/usr/include/fenv.h" 3 4
# 1 "/new-system/usr/include/bits/fenv.h" 1 3 4
# 23 "/new-system/usr/include/bits/fenv.h" 3 4
# 24 "/new-system/usr/include/bits/fenv.h" 2 3 4
fenv_t;
# 59 "/new-system/usr/include/fenv.h" 2 3 4
extern int fegetenv (fenv_t *__envp) throw ();
extern int feholdexcept (fenv_t *__envp) throw ();
extern int fesetenv (__const fenv_t *__envp) throw ();
extern int feupdateenv (__const fenv_t *__envp) throw ();
# 1 "/new-system/usr/include/bits/fenvinline.h" 1 3 4
# 116 "/new-system/usr/include/fenv.h" 2 3 4
# 37 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 2 3
# 37 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 2 3
# 46 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 3
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv" 1 3
# 44 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv" 3
  using ::fenv_t;
# 47 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 2 3

/new-system being the sysroot dir used by gcc and where target glibc headers are. Adding "-I/usr/include" also works even if wrong header is picked this time:

subway:/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include$ x86_64-mine-linux-gnu-c++ -x c++-header -O2 -pipe -march=athlon64   -D_GNU_SOURCE   -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/x86_64-mine-linux-gnu -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.4.2/libstdc++-v3/libsupc++ -I/usr/include -O2 -g /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h -E | grep fenv                                       
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 1
# 32 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv"
# 33 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 3
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 1 3
# 32 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 3
# 33 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 3
# 1 "/usr/include/fenv.h" 1 3
# 58 "/usr/include/fenv.h" 3
# 1 "/usr/include/bits/fenv.h" 1 3
# 26 "/usr/include/bits/fenv.h" 3
fenv_t;
# 59 "/usr/include/fenv.h" 2 3
extern int fegetenv (fenv_t *__envp) throw ();
extern int feholdexcept (fenv_t *__envp) throw ();
extern int fesetenv (__const fenv_t *__envp) throw ();
extern int feupdateenv (__const fenv_t *__envp) throw ();
# 1 "/usr/include/bits/fenvinline.h" 1 3
# 116 "/usr/include/fenv.h" 2 3
# 37 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/fenv.h" 2 3
# 37 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 2 3
# 46 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 3
# 1 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv" 1 3
# 44 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv" 3
  using ::fenv_t;
# 47 "/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv" 2 3

As a side note changing the "C" header model from c_global to c_std in libstdc++-v3/configure.host file solves the problem as fenv.h is no longer installed by gcc along with three other headers (two of them being also provided by glibc).

Thanks for your time.
Comment 19 Paolo Carlini 2009-12-22 09:58:16 UTC
Ralf, is this information enough to debug the issue?
Comment 20 Ralf Wildenhues 2009-12-22 21:04:26 UTC
Created attachment 19374 [details]
patch to turn off multiple inclusion guard for fenv.h C++ wrapper

Comment #18 confirms #13.

It is probably sufficient to turn off the inclusion guard for the include_next.  However, it is also a slightly risky thing to do; and I'm
not quite sure whether it is conceptually the right thing to do.  (FWIW,
gnulib uses split inclusion guards for include_next in a number of places.)
(One risk is backward compatibility requirements stemming from including
the header from the installed, possibly older, compiler.)
 
Another strategy that comes to mind is to use -nostdinc++ and then add
the other include headers manually, but that is likely even more risky.

I'd be interested to see how the clfs build fares with this patch.  If
it succeeds, bonus points for also installing the just-built compiler
and then trying to do another cross build using the just-installed
compiler.

Building and testing of a native compiler succeeded on x86_64-unknown-linux-gnu.
Comment 21 armand.potter 2010-01-10 11:27:58 UTC
Build succeeds with the patch. Cannot test the just built compiler yet (have to install the whole new system) but I will post the patch on clfs mailing list for more testing (even if official instructions say to use --disable-libpchstdcxx
)
Comment 22 Paolo Carlini 2010-01-10 12:16:11 UTC
I don't know what you mean exactly by "official", but certainly disabling the build of the PCHs cannot hurt and cannot create any problem, beside the testsuite running slower. Then, if you actually use PCHs in your own work you can of course try to build them at a later time.
Comment 23 Paolo Carlini 2010-01-10 12:17:55 UTC
I don't know what you mean exactly by "official", but certainly disabling the build of the PCHs cannot hurt and cannot create any problem, beside the testsuite running slower. Then, if you actually use PCHs in your own work you can of course try to build them at a later time.

By the way, honestly the fix proposed by Ralf so far seems hackish to me, I can't believe we can't figure out something cleaner and more general...
Comment 24 H.J. Lu 2010-01-10 16:52:32 UTC
(In reply to comment #0)
> I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1 for
> the target system. make fails with the following error message:
> 

> 
> The configure command contained the following options: --prefix=/usr
> --build=x86_64-cross-linux-gnu --host=x86_64-unknown-linux-gnu
> --target=x86_64-unknown-linux-gnu --enable-languages=c,c++ --disable-multilib
> 
> The following environment variables were set before the build started:
> 
> export CC=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-gcc
> export CXX=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-c++
> export AR=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ar
> export AS=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-as
> export LD=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ld
> export NM=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-nm
> export OBJDUMP=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-objdump
> export RANLIB=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ranlib
> export STRIP=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-strip
> export CC_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-gcc
> export CXX_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-c++
> export AR_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ar
> export AS_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-as
> export LD_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ld
> export NM_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-nm
> export OBJDUMP_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-objdump
> export RANLIB_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-ranlib
> export STRIP_FOR_TARGET=${CLFS_CROSS_TOOLS}/usr/bin/${CLFS_TARGET}-strip
> 
> CLFS_CROSS_TOOLS is the path to the gcc cross-compiler. CLFS_TARGET is
> x86_64-unknown-linux-gnu.
> 

Please show me how CLFS_CROSS_TOOLS gcc and binutils are configured.
Comment 25 H.J. Lu 2010-01-10 17:15:46 UTC
(In reply to comment #24)
> 
> Please show me how CLFS_CROSS_TOOLS gcc and binutils are configured.
> 

Properly configured CLFS_CROSS_TOOLS gcc and binutils should
never use native header files/libraries even if they are
the same. Please find out why your x86_64-mine-linux-gnu-c++
searches /usr/include, which is wrong.
Comment 26 Raúl Porcel 2010-05-14 15:07:34 UTC
Why hasn't that patch have been applied?
Comment 27 Paolo Carlini 2010-05-14 15:11:25 UTC
You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf is willing to explain why is the only possible fix. In the meanwhile just disabling the generation of the PCHs works around the problem pretty well and doesn't seem a big deal to me.
Comment 28 Doug Semler 2010-05-14 15:49:48 UTC
I tried adding -nostdinc++ via --enable-cxx-flags configure option, but those aren't passed through to the pch compilation...and I'm not sure that it's appropriate to pass all the --enable-cxx-flags to the pch generation Makefile anyway.

Seems to me that -nostdinc++ would be the correct thing to do (are the cross compiler's header set appropriate for inclusion into the pch??), but it won't necessarily work if the cross-target compiler isn't g++, right?
Comment 29 Ralf Wildenhues 2010-05-16 17:32:18 UTC
(In reply to comment #27)
> You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf
> is willing to explain why is the only possible fix.

Oh, I don't think it's the only possible fix, it's merely the only patch I came up with.  Off-hand, I don't see what else to do though.
Comment 30 Raúl Porcel 2010-06-19 11:31:44 UTC
So...? :)
Comment 31 armand.potter 2010-07-21 21:35:26 UTC
I made some more investigations (a bit late as I am using now --disable-libpchstdcxx like everyone else). IMHO three main options are possible :

1/ Use -nostdinc++ just as native compilers do. Like said in comment #28, it may break if used cross-compiler is incompatible with in-tree c++ headers (can gcc be built that way ?)

2/ Do not use in-tree headers when using a cross-compiler. Not sure it is a good solution and it may break if cross-compiler does not provide correct c++ headers.
 
3/ Use -I=\${includedir} just as when doing canadian cross compilations (see comment #17). Note that I am building a native compiler that runs on another host that the one building it (is that also canadian cross compilation no ?) so -I\${includedir} should be included. It is not because this test fails in libstdc++-v3/configure.ac :

  if test -n "$with_cross_host" &&
     test x"$build_alias" != x"$with_cross_host" &&
     test x"$build" != x"$target";

and this test fails because with-cross-host is not defined in ./configure.ac as host = target (but build != host). Test should be on host (cross_host seems to be deprecated). Also for 3/ to work, '=' needs to be added to -I\${includedir} to force cross-compiler to use sysroot path and to avoid including native headers from build system.
Comment 32 Paolo Carlini 2010-07-21 22:03:21 UTC
Ralf, do you have any opinion on Comment #31? Maybe Armand can try to produce a patch (or alternate patches) and post to the mailing lists in order to make sure knowledgeable people actually have a chance to see the various options.
Comment 33 Paolo Carlini 2010-07-25 15:19:57 UTC
(In reply to comment #31)
> 1/ Use -nostdinc++ just as native compilers do. Like said in comment #28, it
> may break if used cross-compiler is incompatible with in-tree c++ headers (can
> gcc be built that way ?)

This seems like the most reasonable way.  Can you try adding -nostdinc++ to PCHFLAGS in libstdc++-v3/include/Makefile.am and attach a patch to this PR if it works for your setup?

> 2/ Do not use in-tree headers when using a cross-compiler. Not sure it is a
> good solution and it may break if cross-compiler does not provide correct c++
> headers.

And it wouldn't get bugfixes from uninstalled headers.

> 3/ Use -I=\${includedir} just as when doing canadian cross compilations (see
> comment #17). Note that I am building a native compiler that runs on another
> host that the one building it (is that also canadian cross compilation no ?) so
> -I\${includedir} should be included.

Let's investigate this in more detail if (1) fails to solve the issue.
Comment 34 armand.potter 2010-08-01 17:21:33 UTC
Overall 3/ is not that good as in fact it will use directly system headers without any wrapper (from in-tree or installed gcc). 

I tried adding -nostdinc++ to PCHFLAGS and compilation runs OK (not that hard considering I am using gcc 4.5.0 to build gcc 4.5.0). I will do some more tests and eventually will post a patch.
Comment 35 Paolo Carlini 2010-08-02 06:53:04 UTC
Thanks a lot Armand (by the way, many thanks to Ralf too)
Comment 36 Andrew Pinski 2010-08-10 21:51:42 UTC
I am running into this also when doing a candian cross to mips64-linux-gnu.  We had locally reverted the patch for bug 3800 but I know that is wrong. 
Comment 37 Paolo Carlini 2010-08-10 22:18:01 UTC
Thus, does adding -nostdinc++ to the PCHs flags work for you?
Comment 38 Andrew Pinski 2010-08-10 22:19:02 UTC
(In reply to comment #37)
> Thus, does adding -nostdinc++ to the PCHs flags work for you?
Testing that right now.  
Comment 39 Andrew Pinski 2010-08-11 01:12:30 UTC
(In reply to comment #38)
> (In reply to comment #37)
> > Thus, does adding -nostdinc++ to the PCHs flags work for you?
> Testing that right now.  

No it did not for uclibc:
mips64-octeon-linux-gnu-c++ -L/data/src/gcc-cavium/clean/trunk/build-linux-native/./ld  -mabi=n32 -muclibc -Winvalid-pch -x c++-header -g -O2 --sysroot=/data/src/gcc-cavium/clean/trunk/tools/mips64-octeon-linux-gnu/sys-root -D_GNU_SOURCE -minterlink-mips16 --sysroot=/data/src/gcc-cavium/clean/trunk/tools/mips64-octeon-linux-gnu/sys-root  -nostdinc++ -I/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include/mips64-octeon-linux-gnu -I/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include -I/data/src/gcc-cavium/clean/trunk/src/libstdc++-v3/libsupc++ -O2 -g /data/src/gcc-cavium/clean/trunk/src/libstdc++-v3/include/precompiled/stdtr1c++.h -o mips64-octeon-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
In file included from /data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include/tr1/cfenv:41,
                 from /data/src/gcc-cavium/clean/trunk/src/libstdc++-v3/include/precompiled/stdtr1c++.h:38:
/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include/fenv.h:41:24: error: fenv.h: No such file or directory
Comment 40 Andrew Pinski 2010-08-11 01:19:57 UTC
c++config.h:#define _GLIBCXX_HAVE_FENV_H 1

is happening for uclibc for the Canadian build but not for the cross:
c++config.h:/* #undef _GLIBCXX_HAVE_FENV_H */
Comment 41 Paolo Carlini 2010-08-11 01:23:56 UTC
We need a build system expert here.
Comment 42 Andrew Pinski 2010-08-11 01:28:13 UTC
Actually looks like a bug in our specs somehow; it is not related to this issue at all.  But the fix for using -nostdinc++ fixed the real issue.
Comment 43 Paolo Carlini 2010-08-11 07:08:29 UTC
Ok, even more obscure ;) Can you further investigate? Possibly pinging somebody knowledgeable about the specs? Before applying to the library the -nostdinc++ bits I'd like to make sure we fully understand the issue. Thanks...
Comment 44 Boris Kolpackov 2010-09-02 08:23:43 UTC
I just ran into the same issue building (native) mingw32 GCC 4.5.1 using a x86-64 to mingw32 cross compiler. Adding -nostdinc++ to PCHFLAGS fixed this for me as well. 

I also would like to point out that when building in this configuration the target libraries (libgcc, libstc++) are built using the cross-compiler. Since these libraries are internal to GCC (and can theoretically track the GCC version), I think it is reasonable to expect that the cross and native compilers are the exact same version of GCC. Using different versions in this setup is just asking for trouble.
Comment 45 Paolo Carlini 2010-09-02 09:42:24 UTC
Paolo (Bonzini), Ralf, I'm going to add -nostdinc++ to PCHFLAGS in include/Makefile.am. Are there any risks of regressions?
Comment 46 Paolo Bonzini 2010-09-02 12:44:42 UTC
Subject: Re:  [4.3/4.4/4.5/4.6 Regression] cannot build
 gcc-4.4.1: fenv_t has not been declared

> Paolo (Bonzini), Ralf, I'm going to add -nostdinc++ to PCHFLAGS in
> include/Makefile.am. Are there any risks of regressions?

I don't think there is risk of regressions, but I'm not very familiar
with where PCH is used.

However, I'm told it is not very much used.  Alternatively we could
time how much time the stdc++ PCH actually saves (if anything?) during
make check, and kill it altogether for 4.6.

Paolo
Comment 47 Paolo Carlini 2010-09-02 14:10:07 UTC
Ok, Paolo, let's give this small change a try. About PCHs saving time during make check, that seems uncontroversial, I can provide some numbers later, but if you just try removing the generated PCHs by hand, then run again make check inside libstdc++-v3/testsuite, you will certainly notice a big difference, I would guess close to 2x.
Comment 48 paolo@gcc.gnu.org 2010-09-02 14:13:30 UTC
Subject: Bug 40974

Author: paolo
Date: Thu Sep  2 14:13:00 2010
New Revision: 163777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163777
Log:
2010-09-02  Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/40974
	* include/Makefile.am: Add -nostdinc++ to PCHFLAGS.
	* include/Makefile.in: Regenerate.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/Makefile.am
    trunk/libstdc++-v3/include/Makefile.in

Comment 49 Paolo Carlini 2010-09-02 16:07:02 UTC
Confirmed ~ 2x on my i7.
Comment 50 Richard Biener 2010-09-30 11:09:47 UTC
So, is this fixed anywhere?
Comment 51 Richard Biener 2010-11-12 13:49:43 UTC
Please someone tell us if this issue is fixed.  Please also someone fill
out Known-to-work revisions.
Comment 52 Richard Biener 2011-06-27 12:13:16 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 53 Jakub Jelinek 2012-03-13 12:46:11 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 54 vde 2013-02-18 05:09:33 UTC
same issue trying to compile gcc 4.7.2 for mips - by openWRT toolchain for AR-71XXX

mips-openwrt-linux-uclibc-c++     -x c++-header -nostdinc++ -g -Os -I/opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/mips-openwrt-linux-uclibc/libstdc++-v3/include/mips-openwrt-linux-uclibc -I/opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/mips-openwrt-linux-uclibc/libstdc++-v3/include -I/opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/libstdc++-v3/include/precompiled/stdc++.h \
-o mips-openwrt-linux-uclibc/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from /opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/mips-openwrt-linux-uclibc/libstdc++-v3/include/cfenv:41:0,
                 from /opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/libstdc++-v3/include/precompiled/stdc++.h:54:
/opt/open-WRT/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/gcc-linaro-4.7-2012.12/mips-openwrt-linux-uclibc/libstdc++-v3/include/fenv.h:36:24: fatal error: fenv.h: No such file or directory
compilation terminated.


configured with

AR=mips-openwrt-linux-uclibc-ar \
AS="mips-openwrt-linux-uclibc-gcc -c -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -mno-branch-likely -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float" \
LD=mips-openwrt-linux-uclibc-ld NM=mips-openwrt-linux-uclibc-nm CC="mips-openwrt-linux-uclibc-gcc" \
GCC="mips-openwrt-linux-uclibc-gcc" \
CXX="mips-openwrt-linux-uclibc-g++" \
RANLIB=mips-openwrt-linux-uclibc-ranlib \
STRIP=mips-openwrt-linux-uclibc-strip OBJCOPY=mips-openwrt-linux-uclibc-objcopy \
OBJDUMP=mips-openwrt-linux-uclibc-objdump \
SIZE=mips-openwrt-linux-uclibc-size \
./configure  \
--build=i686-redhat-linux \
--host=mips-openwrt-linux-uclibc \
--target=mips-openwrt-linux-uclibc \
--enable-languages="c,c++" --enable-shared --disable-__cxa_atexit --enable-target-optspace \
--with-gnu-ld --disable-nls --disable-libmudflap --disable-multilib --enable-threads  \
--with-float=soft  \
--with-gmp=/opt/open-WRT/trunk/staging_dir/target-mips_r2_uClibc-0.9.33.2 \
--with-mpfr=/opt/open-WRT/trunk/staging_dir/target-mips_r2_uClibc-0.9.33.2 \
--with-mpc=/opt/open-WRT/trunk/staging_dir/target-mips_r2_uClibc-0.9.33.2 \
--disable-decimal-float --with-mips-plt --disable-libssp --disable-tls \
--with-slibdir=/opt/open-WRT/trunk/staging_dir/toolchain-mips_r2_gcc-4.7.2_uClibc-0.9.33.2/lib \
--with-sysroot=/opt/open-WRT/trunk/staging_dir/target-mips_r2_uClibc-0.9.33.2
Comment 55 Jakub Jelinek 2013-04-12 15:16:20 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 56 Richard Biener 2014-06-12 13:43:32 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 57 Jakub Jelinek 2014-12-19 13:33:26 UTC
GCC 4.8.4 has been released.
Comment 58 Richard Biener 2015-06-23 08:15:55 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 59 Jakub Jelinek 2015-06-26 19:57:31 UTC
GCC 4.9.3 has been released.
Comment 60 Jonathan Wakely 2016-01-12 17:11:59 UTC
Is anyone still seeing this with 4.9.3 or later?
Comment 61 Andrew Pinski 2016-07-31 10:08:01 UTC
No response in 6 months so closing