[Bug libstdc++/40974] New: cannot build gcc-4.4.1: fenv_t has not been declared

[Bug libstdc++/40974] New: cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

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.


-- 
           Summary: cannot build gcc-4.4.1: fenv_t has not been declared
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: booleandomain at gmail dot com
 GCC build triplet: x86_64-cross-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-08-05 22:26 -------
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

------- Comment #2 from booleandomain at gmail dot com  2009-08-06 19:21 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

------- Comment #3 from booleandomain at gmail dot com  2009-08-06 20:20 -------
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2009-08-07 08:22 -------
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?!?)


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ralf dot Wildenhues at gmx
                   |                            |dot de, bonzini at gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[bonzini at gnu dot org]

------- Comment #5 from bonzini at gnu dot org  2009-08-07 09:46 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2009-08-07 10:12 -------
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[bonzini at gnu dot org]

------- Comment #7 from bonzini at gnu dot org  2009-08-07 10:45 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

------- Comment #8 from booleandomain at gmail dot com  2009-08-07 11:58 -------
Created an attachment (id=18316)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18316&action=view)
x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

------- Comment #9 from booleandomain at gmail dot com  2009-08-07 12:00 -------
Created an attachment (id=18317)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18317&action=view)
x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

------- Comment #10 from booleandomain at gmail dot com  2009-08-07 12:03 -------
Created an attachment (id=18318)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18318&action=view)
build-stage1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[booleandomain at gmail dot com]

------- Comment #11 from booleandomain at gmail dot com  2009-08-07 12:10 -------
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"...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2009-09-26 19:44 -------
fenv.h should come from glibc ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armand dot potter at free dot fr]

------- Comment #13 from armand dot potter at free dot fr  2009-12-15 20:48 -------
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. 
~                                                                               


-- 

armand dot potter at free dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |armand dot potter at free
                   |                            |dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #14 from paolo dot carlini at oracle dot com  2009-12-16 16:17 -------
Paolo, Ralf, I'd like to resolve this one for 4.5.0. Any idea?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[bonzini at gnu dot org]

------- Comment #15 from bonzini at gnu dot org  2009-12-16 17:30 -------
Well, the solution could be disable PCH by default. :-)  Is anybody using
it?...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #16 from paolo dot carlini at oracle dot com  2009-12-16 19:15 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[rwild at gcc dot gnu dot org]

------- Comment #17 from rwild at gcc dot gnu dot org  2009-12-16 21:51 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armand dot potter at free dot fr]

------- Comment #18 from armand dot potter at free dot fr  2009-12-19 15:44 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #19 from paolo dot carlini at oracle dot com  2009-12-22 09:58 -------
Ralf, is this information enough to debug the issue?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[rwild at gcc dot gnu dot org]

------- Comment #20 from rwild at gcc dot gnu dot org  2009-12-22 21:04 -------
Created an attachment (id=19374)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19374&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armand dot potter at free dot fr]

------- Comment #21 from armand dot potter at free dot fr  2010-01-10 11:27 -------
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
)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #22 from paolo dot carlini at oracle dot com  2010-01-10 12:16 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #23 from paolo dot carlini at oracle dot com  2010-01-10 12:17 -------
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[hjl dot tools at gmail dot com]

------- Comment #24 from hjl dot tools at gmail dot com  2010-01-10 16:52 -------
(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.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[hjl dot tools at gmail dot com]

------- Comment #25 from hjl dot tools at gmail dot com  2010-01-10 17:15 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armin76 at gentoo dot org]

------- Comment #26 from armin76 at gentoo dot org  2010-05-14 15:07 -------
Why hasn't that patch have been applied?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #27 from paolo dot carlini at oracle dot com  2010-05-14 15:11 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[dougsemler at gmail dot com]

------- Comment #28 from dougsemler at gmail dot com  2010-05-14 15:49 -------
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?


-- 

dougsemler at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dougsemler at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[rwild at gcc dot gnu dot org]

------- Comment #29 from rwild at gcc dot gnu dot org  2010-05-16 17:32 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armin76 at gentoo dot org]

------- Comment #30 from armin76 at gentoo dot org  2010-06-19 11:31 -------
So...? :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armand dot potter at free dot fr]

------- Comment #31 from armand dot potter at free dot fr  2010-07-21 21:35 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #32 from paolo dot carlini at oracle dot com  2010-07-21 22:03 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #33 from paolo dot carlini at oracle dot com  2010-07-25 15:19 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armand dot potter at free dot fr]

------- Comment #34 from armand dot potter at free dot fr  2010-08-01 17:21 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #35 from paolo dot carlini at oracle dot com  2010-08-02 06:53 -------
Thanks a lot Armand (by the way, many thanks to Ralf too)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

------- Comment #36 from pinskia at gcc dot gnu dot org  2010-08-10 21:51 -------
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. 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
            Summary|cannot build gcc-4.4.1:     |[4.3/4.4/4.5/4.6 Regression]
                   |fenv_t has not been declared|cannot build gcc-4.4.1:
                   |                            |fenv_t has not been declared
   Target Milestone|---                         |4.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-08-10 22:00:24
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #37 from paolo dot carlini at oracle dot com  2010-08-10 22:18 -------
Thus, does adding -nostdinc++ to the PCHs flags work for you?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

------- Comment #38 from pinskia at gcc dot gnu dot org  2010-08-10 22:19 -------
(In reply to comment #37)
> Thus, does adding -nostdinc++ to the PCHs flags work for you?
Testing that right now.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

------- Comment #39 from pinskia at gcc dot gnu dot org  2010-08-11 01:12 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

------- Comment #40 from pinskia at gcc dot gnu dot org  2010-08-11 01:19 -------
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 */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #41 from paolo dot carlini at oracle dot com  2010-08-11 01:23 -------
We need a build system expert here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

------- Comment #42 from pinskia at gcc dot gnu dot org  2010-08-11 01:28 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #43 from paolo dot carlini at oracle dot com  2010-08-11 07:08 -------
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[boris at kolpackov dot net]

------- Comment #44 from boris at kolpackov dot net  2010-09-02 08:23 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #45 from paolo dot carlini at oracle dot com  2010-09-02 09:42 -------
Paolo (Bonzini), Ralf, I'm going to add -nostdinc++ to PCHFLAGS in
include/Makefile.am. Are there any risks of regressions?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[bonzini at gnu dot org]

------- Comment #46 from bonzini at gnu dot org  2010-09-02 12:44 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #47 from paolo dot carlini at oracle dot com  2010-09-02 14:10 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo at gcc dot gnu dot org]

------- Comment #48 from paolo at gcc dot gnu dot org  2010-09-02 14:13 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

------- Comment #49 from paolo dot carlini at oracle dot com  2010-09-02 16:07 -------
Confirmed ~ 2x on my i7.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974