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.
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...
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.
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...
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?!?)
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?
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...
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.
Created attachment 18316 [details] x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h
Created attachment 18317 [details] x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h
Created attachment 18318 [details] build-stage1
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"...
fenv.h should come from glibc ...
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. ~
Paolo, Ralf, I'd like to resolve this one for 4.5.0. Any idea?
Well, the solution could be disable PCH by default. :-) Is anybody using it?...
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.
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.
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.
Ralf, is this information enough to debug the issue?
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.
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 )
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.
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...
(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.
(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.
Why hasn't that patch have been applied?
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.
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?
(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.
So...? :)
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.
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.
(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.
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.
Thanks a lot Armand (by the way, many thanks to Ralf too)
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.
Thus, does adding -nostdinc++ to the PCHs flags work for you?
(In reply to comment #37) > Thus, does adding -nostdinc++ to the PCHs flags work for you? Testing that right now.
(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
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 */
We need a build system expert here.
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.
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...
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.
Paolo (Bonzini), Ralf, I'm going to add -nostdinc++ to PCHFLAGS in include/Makefile.am. Are there any risks of regressions?
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
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.
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
Confirmed ~ 2x on my i7.
So, is this fixed anywhere?
Please someone tell us if this issue is fixed. Please also someone fill out Known-to-work revisions.
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
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
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
Is anyone still seeing this with 4.9.3 or later?
No response in 6 months so closing