[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #77 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4fde88e5dd152fe866a97b12e0f8229970d15cb3 commit r12-6406-g4fde88e5dd152fe866a97b12e0f8229970d15cb3 Author: Jonathan Wakely Date: Fri Jan 7 15:21:03 2022 + libstdc++: Add -nostdinc++ for c++17 sources [PR100017] When building a build!=host compiler, the just-built gcc can't be used to build the target libstdc++ (because it is built for the host triplet, not the build triplet). The top-level configure.ac sets up the build flags for libstdc++ (and other "raw_cxx" libs) like this: GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX, [gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc -nostdinc++ -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs], c++) The -nostdinc++ flag is only used for the IN-TREE-TOOL, i.e. when using the just-built gcc/xgcc compiler. This means that the cross-compiler used to build libstdc++ will add its own libstdc++ headers to the include path. That results in the #include in src/c++17/floating_to_chars.cc and src/c++17/floating_from_chars.cc doing #include_next and finding the libstdc++ fenv.h wrapper from the host compiler. Because that has the same include guard as the in the libstdc++ we're trying to build, we never reach the underlying from libc. That results in several errors of the form: error: 'fenv_t' has not been declared in '::' The most correct fix would be to add -nostdinc++ to the RAW_CXX_FOR_TARGET variable in configure.ac, or the RAW_CXX_TARGET_EXPORTS variable in Makefile.tpl. Another solution would be to make the libstdc++ wrapper use _GLIBCXX_INCLUDE_NEXT_C_HEADERS like our and other C header wrappers. For now though, the simplest and safest solution is to just add -nostdinc++ to the CXXFLAGS used for src/c++17/*.cc, which is what this does. libstdc++-v3/ChangeLog: PR libstdc++/100017 * src/c++17/Makefile.am (AM_CXXFLAGS): Add -nostdinc++. * src/c++17/Makefile.in: Regenerate.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #76 from Jonathan Wakely --- (In reply to cqwrteur from comment #74) > Also another patch on fixing freestanding C++ build There's a patch on PR 103866 to fix freestanding, but that's irrelevant to this bug. Please try to stay on topic and stop going off on tangents. There are already 76 comments here, and half of them are from you, and most of those are unnecessary or unhelpful. When you can't stop yourself from vomiting your stupid opinions all over bugzilla it makes it difficult and unpleasant to try and follow the bugs. And so less likely to get fixed.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #75 from cqwrteur --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587838.html
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #74 from cqwrteur --- (In reply to cqwrteur from comment #73) > (In reply to Jakub Jelinek from comment #72) > > Guess another option would be to do that > > RAW_CXX_FLAGS_FOR_TARGET="$RAW_CXX_FLAGS_FOR_TARGET -nostdinc++" > > in the toplevel configure.ac after all the GCC_TARGET_TOOL lines. > > While GCC_TARGET_TOOL does AC_SUBST on the second argument, so > > AC_SUBST(RAW_CXX_FLAGS_FOR_TARGET), in autoconf AC_SUBST just remembers > > that it should be substituted and does the substitutions late, so when the > > var is changed in between it will propagate to the Makefiles etc. > > > > --- configure.ac2022-01-04 23:11:22.153595595 +0100 > > +++ configure.ac2022-01-06 21:59:49.274985505 +0100 > > @@ -3669,6 +3669,8 @@ GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET, > > GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, [binutils/windres]) > > GCC_TARGET_TOOL(windmc, WINDMC_FOR_TARGET, WINDMC, [binutils/windmc]) > > > > +RAW_CXX_FOR_TARGET="$RAW_CXX_FOR_TARGET -nostdinc++" > > + > > AC_SUBST(FLAGS_FOR_TARGET) > > AC_SUBST(RAW_CXX_FOR_TARGET) > > > > > > completely untested... > > Also. Can I propose another patch that fixes multilib canadian builds for > mingw-w64 and cygwin? i think I have a patch to fix that. > > The build sripts in GCC copy wrong DLLs when we build multilibs when we > build Canadians. It is also a problem for native but native is usually buggy > that cannot build multilibs. Also another patch on fixing freestanding C++ build
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #73 from cqwrteur --- (In reply to Jakub Jelinek from comment #72) > Guess another option would be to do that > RAW_CXX_FLAGS_FOR_TARGET="$RAW_CXX_FLAGS_FOR_TARGET -nostdinc++" > in the toplevel configure.ac after all the GCC_TARGET_TOOL lines. > While GCC_TARGET_TOOL does AC_SUBST on the second argument, so > AC_SUBST(RAW_CXX_FLAGS_FOR_TARGET), in autoconf AC_SUBST just remembers > that it should be substituted and does the substitutions late, so when the > var is changed in between it will propagate to the Makefiles etc. > > --- configure.ac 2022-01-04 23:11:22.153595595 +0100 > +++ configure.ac 2022-01-06 21:59:49.274985505 +0100 > @@ -3669,6 +3669,8 @@ GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET, > GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, [binutils/windres]) > GCC_TARGET_TOOL(windmc, WINDMC_FOR_TARGET, WINDMC, [binutils/windmc]) > > +RAW_CXX_FOR_TARGET="$RAW_CXX_FOR_TARGET -nostdinc++" > + > AC_SUBST(FLAGS_FOR_TARGET) > AC_SUBST(RAW_CXX_FOR_TARGET) > > > completely untested... Also. Can I propose another patch that fixes multilib canadian builds for mingw-w64 and cygwin? i think I have a patch to fix that. The build sripts in GCC copy wrong DLLs when we build multilibs when we build Canadians. It is also a problem for native but native is usually buggy that cannot build multilibs.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #72 from Jakub Jelinek --- Guess another option would be to do that RAW_CXX_FLAGS_FOR_TARGET="$RAW_CXX_FLAGS_FOR_TARGET -nostdinc++" in the toplevel configure.ac after all the GCC_TARGET_TOOL lines. While GCC_TARGET_TOOL does AC_SUBST on the second argument, so AC_SUBST(RAW_CXX_FLAGS_FOR_TARGET), in autoconf AC_SUBST just remembers that it should be substituted and does the substitutions late, so when the var is changed in between it will propagate to the Makefiles etc. --- configure.ac2022-01-04 23:11:22.153595595 +0100 +++ configure.ac2022-01-06 21:59:49.274985505 +0100 @@ -3669,6 +3669,8 @@ GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET, GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, [binutils/windres]) GCC_TARGET_TOOL(windmc, WINDMC_FOR_TARGET, WINDMC, [binutils/windmc]) +RAW_CXX_FOR_TARGET="$RAW_CXX_FOR_TARGET -nostdinc++" + AC_SUBST(FLAGS_FOR_TARGET) AC_SUBST(RAW_CXX_FOR_TARGET) completely untested...
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #71 from Jonathan Wakely --- Tomorrow I'll test my more complete patch based on comment 7 (and comment 12) as that should also solve it, and without changes to configury. Conceptually, adding -nostdinc++ seems cleaner (it's what we already do when building the target libs with the just-built gcc) but I'm less certain about unwanted side effects.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #70 from Jonathan Wakely --- We're using it to build libstdc++ so it needs to be very very close to gcc in terms of language support, and libstdc++ uses all kinds of flags like -fno-implicit-templates that are gcc-specific. I don't think it's really plausible to build libstdc++ with anything except a gcc that closely matches the version of libstdc++ being built.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #69 from Jakub Jelinek --- Do we have a guarantee that $(RAW_CXX_FOR_TARGET) is always some version of GCC? I mean, other compilers might not support -nostdinc++ option at all (older versions of GCC might not either, but we only support GCC that can do C++11 now and those all support it).
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #68 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #57) > I don't see how the patch could be correct. > [...] > So, if CXX_FOR_TARGET starts with /, e.g. /opt/gcc-11.1/bin/g++ , then > the above will use dirname /opt/gcc-11.1/bin/g++ and set ac_dir to > /opt/gcc-11.1/bin > But with the proposed change, $RAW_CXX_FOR_TARGET will be > /opt/gcc-11.1/bin/g++ -nostdinc++ and dirname will fail miserably and not > set ac_dir to anything: > dirname /opt/gcc-11.1/bin/g++ -nostdinc++ > dirname: invalid option -- 'n' > Try 'dirname --help' for more information. Jakub's analysis is correct. If the cross compiler is found in PATH then the patch works OK. The configure output shows: checking where to find the target c++... pre-installed checking where to find the target c++ for libstdc++... pre-installed If you build with something like CXX_FOR_TARGET=/home/jwakely/gcc/aarch64/bin/aarch64-none-linux-gnu-g++ then configure shows: checking where to find the target c++... pre-installed in /home/jwakely/gcc/aarch64/bin checking where to find the target c++ for libstdc++... pre-installed in /home/jwakely/gcc/aarch64/bin But with the patch that prints an error: checking where to find the target c++... pre-installed in /home/jwakely/gcc/aarch64/bin checking where to find the target c++ for libstdc++... dirname: invalid option -- 'n' Try 'dirname --help' for more information. pre-installed in I don't think that actually causes a problem though. The build still works. The dirname command is only used to print the result during configure. It's not great though. If we do this instead, then we don't have that problem: diff --git a/Makefile.in b/Makefile.in index 79c77fccf0f..ada25b8f11b 100644 --- a/Makefile.in +++ b/Makefile.in @@ -329,7 +329,7 @@ BASE_TARGET_EXPORTS = \ RAW_CXX_TARGET_EXPORTS = \ $(BASE_TARGET_EXPORTS) \ CXX_FOR_TARGET="$(RAW_CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \ - CXX="$(RAW_CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX; + CXX="$(RAW_CXX_FOR_TARGET) -nostdinc++ $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX; NORMAL_TARGET_EXPORTS = \ $(BASE_TARGET_EXPORTS) \ diff --git a/Makefile.tpl b/Makefile.tpl index ef58fac2b9a..fc10c7a771d 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -332,7 +332,7 @@ BASE_TARGET_EXPORTS = \ RAW_CXX_TARGET_EXPORTS = \ $(BASE_TARGET_EXPORTS) \ CXX_FOR_TARGET="$(RAW_CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \ - CXX="$(RAW_CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX; + CXX="$(RAW_CXX_FOR_TARGET) -nostdinc++ $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX; NORMAL_TARGET_EXPORTS = \ $(BASE_TARGET_EXPORTS) \ I think that will mean we get -nostdinc++ twice for build==host builds, but that's harmless. The other reason I'm unsure about adding -nostdinc++ to RAW_CXX_FOR_TARGET is that it's also used for building other target libs, specifically libsanitizer and libvtv. I think it's correct for them too.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #67 from Alexander von Gluck --- (In reply to cqwrteur from comment #65) > > Difficult? hmmm. Even middle school kids could... Uh uh. Yeah i'm just tuning you out at this point. *anyway* for the adults left in the thread. Jonathan, let me know if theres anything I can test out to help you. Thanks! -- Alex
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #66 from Jonathan Wakely --- (In reply to cqwrteur from comment #63) > so what's your solution to fix this problem? Are we going to fix it after > GCC13? I'm working on it right now, but it would help if you would just shut the hell up. Clang is off topic here. Your stupid opinions on other people's projects are off topic here. Just shut up.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #65 from cqwrteur --- (In reply to Jonathan Wakely from comment #62) > But that's off topic for GCC's bugzilla, please try to focus. Is that because #if _GLIBCXX_HAVE_FENV_H # include #endif here _GLIBCXX_HAVE_FENV_H in the libstdc++ build scripts fails to detect fenv.h? What about replacing it with #if __has_include() ? (In reply to Alexander von Gluck from comment #64) > (In reply to cqwrteur from comment #61) > > TBH, I failed to see how cross-compile in llvm is simple compared to GCC. > > I mean... bootstrap. Compiling Canadian toolchains to compile non-Canadian > toolchains is a pretty difficult task. It's a big reason the BSD's went > clang. > > *ANYWAY* wasn't looking to start a holy war.. just point out that Canadian > builds in gcc are important and should likely have a few base tests. > > (In reply to Jonathan Wakely from comment #62) > > But that's off topic for GCC's bugzilla, please try to focus. > > Indeed. Back on topic, the patchset listed definitely does solve the issue > for us. I didn't commit it to our gcc fork (that we plan on working to > upstream for Haiku support) though since a final iteration wasn't decided / > committed yet here. Difficult? hmmm. Even middle school kids could easily do this. I guess nowadays people just randomly search things on the internet for wrong sources and rely on the things like cross-ng that adds difficulties to it. In fact cross-ng just makes simple things hard not simple. I am against all these auto build scripts. They just make simple things hard and constantly break for all sorts of reasons.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #64 from Alexander von Gluck --- (In reply to cqwrteur from comment #61) > TBH, I failed to see how cross-compile in llvm is simple compared to GCC. I mean... bootstrap. Compiling Canadian toolchains to compile non-Canadian toolchains is a pretty difficult task. It's a big reason the BSD's went clang. *ANYWAY* wasn't looking to start a holy war.. just point out that Canadian builds in gcc are important and should likely have a few base tests. (In reply to Jonathan Wakely from comment #62) > But that's off topic for GCC's bugzilla, please try to focus. Indeed. Back on topic, the patchset listed definitely does solve the issue for us. I didn't commit it to our gcc fork (that we plan on working to upstream for Haiku support) though since a final iteration wasn't decided / committed yet here.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #63 from cqwrteur --- (In reply to Jonathan Wakely from comment #62) > But that's off topic for GCC's bugzilla, please try to focus. so what's your solution to fix this problem? Are we going to fix it after GCC13?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #62 from Jonathan Wakely --- But that's off topic for GCC's bugzilla, please try to focus.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #61 from cqwrteur --- (In reply to Alexander von Gluck from comment #56) > Canadian builds are pretty important in GCC. > > clang doesn't really need Canadian builds since they support all targets out > of the box on every platform, but we don't have that luxury with GCC. TBH, I failed to see how cross-compile in llvm is simple compared to GCC. The problem is that you still need to build libc, you still need to build compiler-rt, you still need to build libcxx, libcxxabi, libunwind whatever manually one by one. Building them wastes more time than building a GCC cross compiler. That is why people just build GCC cross compiler and then use clang --target to GCC's libraries.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #60 from cqwrteur --- (In reply to Alexander von Gluck from comment #56) > Canadian builds are pretty important in GCC. > > clang doesn't really need Canadian builds since they support all targets out > of the box on every platform, but we don't have that luxury with gcc. > > With that said, the proposed patch solved the issue for us and we applied it > to our toolchains here: > https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/ > gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset Canadian Compilation 11 : Canadian Compile LLVM/clang with x86_64-w64-mingw32-gcc posix. https://youtu.be/U3KtVhLxlK4
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #59 from cqwrteur ---
(In reply to Jakub Jelinek from comment #57)
> I don't see how the patch could be correct.
> Looking at RAW_CXX_FOR_TARGET in configure, I see:
> (starting with the line you're proposing to change):
> RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
> ...
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking where to find the target
> c++ for libstdc++" >&5
> $as_echo_n "checking where to find the target c++ for libstdc++... " >&6; }
> if test "x${build}" != "x${host}" ; then
> if expr "x$RAW_CXX_FOR_TARGET" : "x/" > /dev/null; then
> # We already found the complete path
> ac_dir=`dirname $RAW_CXX_FOR_TARGET`
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed in
> $ac_dir" >&5
> $as_echo "pre-installed in $ac_dir" >&6; }
> else
> # Canadian cross, just use what we found
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed" >&5
> $as_echo "pre-installed" >&6; }
> fi
> else
>
> So, if CXX_FOR_TARGET starts with /, e.g. /opt/gcc-11.1/bin/g++ , then
> the above will use dirname /opt/gcc-11.1/bin/g++ and set ac_dir to
> /opt/gcc-11.1/bin
> But with the proposed change, $RAW_CXX_FOR_TARGET will be
> /opt/gcc-11.1/bin/g++ -nostdinc++ and dirname will fail miserably and not
> set ac_dir to anything:
> dirname /opt/gcc-11.1/bin/g++ -nostdinc++
> dirname: invalid option -- 'n'
> Try 'dirname --help' for more information.
So is this just an issue to libstdc++'s configure script only? Why the autotool
fails to find header files?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #58 from cqwrteur --- (In reply to Alexander von Gluck from comment #56) > Canadian builds are pretty important in GCC. > > clang doesn't really need Canadian builds since they support all targets out > of the box on every platform, but we don't have that luxury with gcc. > > With that said, the proposed patch solved the issue for us and we applied it > to our toolchains here: > https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/ > gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset clang does need Canadian builds. For example Canadian compile a clang runs on windows but builds on linux. Or Canadian compile a low power aarch64 raspi from x86_64 ryzen powerful machine. For example. https://bitbucket.org/ejsvifq_mabmip/windows-hosted-llvm-clang/src/master/ I Canadian compile this from linux,
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #57 from Jakub Jelinek ---
I don't see how the patch could be correct.
Looking at RAW_CXX_FOR_TARGET in configure, I see:
(starting with the line you're proposing to change):
RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
...
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking where to find the target c++
for libstdc++" >&5
$as_echo_n "checking where to find the target c++ for libstdc++... " >&6; }
if test "x${build}" != "x${host}" ; then
if expr "x$RAW_CXX_FOR_TARGET" : "x/" > /dev/null; then
# We already found the complete path
ac_dir=`dirname $RAW_CXX_FOR_TARGET`
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed in $ac_dir"
>&5
$as_echo "pre-installed in $ac_dir" >&6; }
else
# Canadian cross, just use what we found
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed" >&5
$as_echo "pre-installed" >&6; }
fi
else
So, if CXX_FOR_TARGET starts with /, e.g. /opt/gcc-11.1/bin/g++ , then
the above will use dirname /opt/gcc-11.1/bin/g++ and set ac_dir to
/opt/gcc-11.1/bin
But with the proposed change, $RAW_CXX_FOR_TARGET will be /opt/gcc-11.1/bin/g++
-nostdinc++ and dirname will fail miserably and not set ac_dir to anything:
dirname /opt/gcc-11.1/bin/g++ -nostdinc++
dirname: invalid option -- 'n'
Try 'dirname --help' for more information.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #56 from Alexander von Gluck --- Canadian builds are pretty important in GCC. clang doesn't really need Canadian builds since they support all targets out of the box on every platform, but we don't have that luxury with gcc. With that said, the proposed patch solved the issue for us and we applied it to our toolchains here: https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #55 from cqwrteur --- (In reply to Jonathan Wakely from comment #54) > (In reply to Andrew Aladjev from comment #38) > > Sure, patches works perfect. But we need somehow decrease the chance of > > similar regressions in future. It is possible by adding any basic "canadian" > > build into the list of tests to be done before release. We should not try to > > add such test into codebase itself, we need just to intrigue any of core gcc > > developers to add this test into the virtual checklist. > > There is no "virtual checklist". If you care about a particular > configuration then YOU should be submitting results to the gcc-testresults > mailing list to report on the status of that config. > > The GCC devs are testing the configs and the targets that THEY care about. so you mean GCC devs do not care about Canadian compilation?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #54 from Jonathan Wakely --- (In reply to Andrew Aladjev from comment #38) > Sure, patches works perfect. But we need somehow decrease the chance of > similar regressions in future. It is possible by adding any basic "canadian" > build into the list of tests to be done before release. We should not try to > add such test into codebase itself, we need just to intrigue any of core gcc > developers to add this test into the virtual checklist. There is no "virtual checklist". If you care about a particular configuration then YOU should be submitting results to the gcc-testresults mailing list to report on the status of that config. The GCC devs are testing the configs and the targets that THEY care about.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #53 from cqwrteur --- (In reply to Jonathan Wakely from comment #52) > (In reply to Andrew Aladjev from comment #35) > > Hello cqwrteur, do you have an influence on core gcc developers? > > He has negative influence. The more he comments on a bug, the less likely I > am to even read it, let alone fix it. lol. but hey. std::format is sometimes 4x slower than stringstream. you wg21 loves it right?? lol
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #52 from Jonathan Wakely --- (In reply to Andrew Aladjev from comment #35) > Hello cqwrteur, do you have an influence on core gcc developers? He has negative influence. The more he comments on a bug, the less likely I am to even read it, let alone fix it.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Alexander von Gluck changed: What|Removed |Added CC||kallisti5 at unixzen dot com --- Comment #51 from Alexander von Gluck --- Just saw this one bootstrapping Haiku riscv64 with gcc 11.1 under Linux. We're quite Canadian. Adding some error spam for others searching for this issue. ``` /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:58:11: error: 'fenv_t' has not been declared in '::' 58 | using ::fenv_t; | ^~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:59:11: error: 'fexcept_t' has not been declared in '::' 59 | using ::fexcept_t; | ^ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:62:11: error: 'feclearexcept' has not been declared in '::' 62 | using ::feclearexcept; | ^ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:63:11: error: 'fegetexceptflag' has not been declared in '::' 63 | using ::fegetexceptflag; | ^~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:64:11: error: 'feraiseexcept' has not been declared in '::' 64 | using ::feraiseexcept; | ^ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:65:11: error: 'fesetexceptflag' has not been declared in '::' 65 | using ::fesetexceptflag; | ^~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:66:11: error: 'fetestexcept' has not been declared in '::' 66 | using ::fetestexcept; | ^~~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:68:11: error: 'fegetround' has not been declared in '::' 68 | using ::fegetround; | ^~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:69:11: error: 'fesetround' has not been declared in '::' 69 | using ::fesetround; | ^~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:71:11: error: 'fegetenv' has not been declared in '::' 71 | using ::fegetenv; | ^~~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:72:11: error: 'feholdexcept' has not been declared in '::' 72 | using ::feholdexcept; | ^~~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:73:11: error:
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #50 from cqwrteur --- Backported GCC 11 patch https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587255.html
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #49 from cqwrteur --- https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587254.html I just send an email to add a patch for this. Jonathan Wakely, can you review the patch here?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #48 from cqwrteur --- (In reply to Jonathan Wakely from comment #46) > I hope to get to it next week. what's the problem of just adding --nostdinc++ for RAW_CXX_FOR_TARGET??
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #47 from cqwrteur --- (In reply to Jonathan Wakely from comment #46) > I hope to get to it next week. lul it is not fixed in entire week.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #46 from Jonathan Wakely --- I hope to get to it next week.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #45 from vvinayag at arm dot com --- (In reply to Jonathan Wakely from comment #44) > *** Bug 103570 has been marked as a duplicate of this bug. *** Hi Jonathan, I see that you plan to fix this soon (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103570#c1), and thank you for that. Do you have a rough estimate of when we would see a fix for this? One of our releases depends on a fix for this issue. Kind regards Vasee
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Jonathan Wakely changed: What|Removed |Added CC||pedro.falcato at gmail dot com --- Comment #44 from Jonathan Wakely --- *** Bug 103570 has been marked as a duplicate of this bug. ***
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #43 from cqwrteur --- Created attachment 51910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51910=edit new patch after today's update Can we just push this to main?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #42 from cqwrteur --- Created attachment 51816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51816=edit patch after today's update to configure add a patch for today's update
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #41 from cqwrteur --- (In reply to Andrew Aladjev from comment #38) > Sure, patches works perfect. But we need somehow decrease the chance of > similar regressions in future. It is possible by adding any basic "canadian" > build into the list of tests to be done before release. We should not try to > add such test into codebase itself, we need just to intrigue any of core gcc > developers to add this test into the virtual checklist. > > Thank you. The only thing you can do is that if you find a build bug, report to bugzilla
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #40 from cqwrteur --- (In reply to Andrew Aladjev from comment #38) > Sure, patches works perfect. But we need somehow decrease the chance of > similar regressions in future. It is possible by adding any basic "canadian" > build into the list of tests to be done before release. We should not try to > add such test into codebase itself, we need just to intrigue any of core gcc > developers to add this test into the virtual checklist. > > Thank you. Issues like this are exactly why i would never use a script (including things like cross-ng) to build anything. I would build everything manually since it is very likely to fail for all sorts of different reasons, neither their testing would fix it since they have to include different libcs (we have hundreds of different libcs) to test each of them, which is not possible.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #39 from cqwrteur --- (In reply to Andrew Aladjev from comment #38) > Sure, patches works perfect. But we need somehow decrease the chance of > similar regressions in future. It is possible by adding any basic "canadian" > build into the list of tests to be done before release. We should not try to > add such test into codebase itself, we need just to intrigue any of core gcc > developers to add this test into the virtual checklist. > > Thank you. You do not need to worry tbh, people like me would test before you. They have much more issues than just a Canadian build tbh. Like copying wrong DLLs for multilibs. Nobody ever built that before probably.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #38 from Andrew Aladjev --- Sure, patches works perfect. But we need somehow decrease the chance of similar regressions in future. It is possible by adding any basic "canadian" build into the list of tests to be done before release. We should not try to add such test into codebase itself, we need just to intrigue any of core gcc developers to add this test into the virtual checklist. Thank you.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #37 from cqwrteur --- (In reply to cqwrteur from comment #36) > (In reply to Andrew Aladjev from comment #35) > > Hello cqwrteur, do you have an influence on core gcc developers? Please > > provide an idea to add at least one "canadian" test before release. > > x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should > > not definitely meet here trying to treat "childhood" issues. > > > > Thank you. > > I built that before. x86_64-pc-linux-gnu -> x86_64-ubuntu-linux-gnu Canadian > native. > > x86_64-pc-linux-gnu build x86_64-w64-mingw32 cross x86_64-ubuntu-linux-gnu > Canadian cross build. > > > That patch works of course. cqwrteur@localhost:~$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/cqwrteur/x86_64-ubuntu-linux-gnu/bin/../libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper Target: x86_64-ubuntu-linux-gnu Configured with: ../../../gcc/configure --disable-werror --disable-nls --enable-languages=c,c++ --enable-multilib --disable-bootstrap --disable-libstdcxx-verbose --with-gxx-libcxx-include-dir=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu_canadian/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/c++/v1 --prefix=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu_canadian/x86_64-ubuntu-linux-gnu --with-pkgversion=cqwrteur --with-multilib-list=m64,m32,mx32 --target=x86_64-ubuntu-linux-gnu --host=x86_64-ubuntu-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210910 (experimental) (cqwrteur) D:\hg>x86_64-ubuntu-linux-gnu-g++ -v Using built-in specs. COLLECT_GCC=x86_64-ubuntu-linux-gnu-g++ COLLECT_LTO_WRAPPER=d:/x86_64-windows-gnu/x86_64-ubuntu-linux-gnu/bin/../libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper.exe Target: x86_64-ubuntu-linux-gnu Configured with: ../../../gcc/configure --disable-nls --disable-werror --prefix=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu --target=x86_64-ubuntu-linux-gnu --host=x86_64-w64-mingw32 --with-gxx-libcxx-include-dir=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/include/c++/v1 --enable-multilib --with-multilib-list=m64,mx32,m32 --disable-libstdcxx-verbose --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211005 (experimental) (GCC)
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #36 from cqwrteur --- (In reply to Andrew Aladjev from comment #35) > Hello cqwrteur, do you have an influence on core gcc developers? Please > provide an idea to add at least one "canadian" test before release. > x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should > not definitely meet here trying to treat "childhood" issues. > > Thank you. I built that before. x86_64-pc-linux-gnu -> x86_64-ubuntu-linux-gnu Canadian native. x86_64-pc-linux-gnu build x86_64-w64-mingw32 cross x86_64-ubuntu-linux-gnu Canadian cross build. That patch works of course.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #35 from Andrew Aladjev --- Hello cqwrteur, do you have an influence on core gcc developers? Please provide an idea to add at least one "canadian" test before release. x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should not definitely meet here trying to treat "childhood" issues. Thank you.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #34 from cqwrteur --- Created attachment 51747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51747=edit Correct Patch by just fixing configure and configure.ac with -nostdinc++ Tested with over 20 canadian cross builds without any issues.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #33 from cqwrteur ---
(In reply to Andrew Aladjev from comment #32)
> I've added include_next_fenv dirty patch. I want just to quickly explain how
> to use it.
>
> First of all I've noticed (many years ago) that gcc developers are making
> releases based on limited set of basic tests. These tests include one self
> compilation using same version of gcc: gcc 11.2.0 amd64 -> gcc 11.2.0 amd64.
> But in reality you have the following case:
>
> gcc #{prev_version} #{platform1} #{env1} -> gcc #{next_version} #{platform2}
> #{env2}
>
> This movement is very hard task in practice, so I've added an additional
> step:
>
> gcc #{prev_version} #{platform1} #{env1} -> dirty gcc #{next_version}
> #{platform2} #{dirty_env2} -> gcc #{next_version} #{platform2} #{env2}
>
> "dirty gcc" and "dirty env" step is very usefull when nobody have a
> solution. You can invent your own dirty bicycle, apply it and you will
> receive clean gcc on target platform in the last step anyway.
>
> You may also review the following repo
> https://github.com/andrew-aladev/test-images with my some test images.
>
> Thank you.
I can ensure your patch is not correct
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #32 from Andrew Aladjev ---
I've added include_next_fenv dirty patch. I want just to quickly explain how to
use it.
First of all I've noticed (many years ago) that gcc developers are making
releases based on limited set of basic tests. These tests include one self
compilation using same version of gcc: gcc 11.2.0 amd64 -> gcc 11.2.0 amd64.
But in reality you have the following case:
gcc #{prev_version} #{platform1} #{env1} -> gcc #{next_version} #{platform2}
#{env2}
This movement is very hard task in practice, so I've added an additional step:
gcc #{prev_version} #{platform1} #{env1} -> dirty gcc #{next_version}
#{platform2} #{dirty_env2} -> gcc #{next_version} #{platform2} #{env2}
"dirty gcc" and "dirty env" step is very usefull when nobody have a solution.
You can invent your own dirty bicycle, apply it and you will receive clean gcc
on target platform in the last step anyway.
You may also review the following repo
https://github.com/andrew-aladev/test-images with my some test images.
Thank you.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #31 from cqwrteur --- (In reply to Andrew Aladjev from comment #30) > Created attachment 51746 [details] > Include fenv dirty patch for gcc 11.2.0 > > Please apply carefully, it is not safe. no. adding -nostdinc++ is the right solution. yours are wrong.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #30 from Andrew Aladjev --- Created attachment 51746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51746=edit Include fenv dirty patch for gcc 11.2.0 Please apply carefully, it is not safe.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #29 from vvinayag at arm dot com --- Can we expect a patch for this upstream?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #28 from cqwrteur --- (In reply to Ofer Shinaar from comment #27) > (In reply to cqwrteur from comment #23) > > (In reply to Jonathan Wakely from comment #22) > > > *** Bug 101060 has been marked as a duplicate of this bug. *** > > > > I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure > > and configure.ac in gcc root repository (not in gcc subdirectory nor > > libstdc++-v3 subdirectory) > > > > Yes. So it is very easy to fix. > > and what if I do want to use libstdc++ ? the first soultion allows me that no. it does not affect how libstdc++ builds. It is a bug in the build process that the GCC will prefer finding headers in the C++ cross compiler. It should not use C++ standard library headers in your cross compiler. Add -nostdinc++ is adding a toggle at the build process that fixes all sorts of issues that relate to the build of libstdc++. It won't affect you for using it after the build. There are some other problems of Canadian compilation here, like copying wrong DLLs when you build with multilibs. Those are separate issues.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #27 from Ofer Shinaar --- (In reply to cqwrteur from comment #23) > (In reply to Jonathan Wakely from comment #22) > > *** Bug 101060 has been marked as a duplicate of this bug. *** > > I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure > and configure.ac in gcc root repository (not in gcc subdirectory nor > libstdc++-v3 subdirectory) > > Yes. So it is very easy to fix. and what if I do want to use libstdc++ ? the first soultion allows me that
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #26 from cqwrteur --- (In reply to Alexey Brodkin from comment #25) > > (In reply to Jonathan Wakely from comment #22) > > > *** Bug 101060 has been marked as a duplicate of this bug. *** > > > > We can fix it today XDXD > > > > PROFIT PROFIT PROFIT!!! > > Given there's a solution/patch suggested by Yujie Yang is there a chance to > get it fixed in upstream sources? > > For the record I'm also seeing initially reported problem when trying to > build canadian cross GCC with Crosstool-NG (well, it's clear build system > doesn't matter but just in case). why do you use Crosstool-NG?? It sucks. Just manually compile by yourself. Simple and no bullshit.
