[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- 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] cannot build gcc-4.4.1: fenv_t has not been declared
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=19374action=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
--- 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=500 --split-size=500 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
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=18316action=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
--- 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=18317action=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
--- 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=18318action=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
--- 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
--- 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
--- 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
