http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-12-29 23:05:25 UTC --- On Thu, Dec 29, 2011 at 10:26:52PM +0000, redi at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 > > (In reply to comment #7) > > Thanks for the condescending email. Testing with GCC is > > exactly how the problem was found. g++ is telling the > > FreeBSD libc++ developers, 'Yes, I support C++11'. The > > FreeBSD libc++ developers are using C++11 features, and > > implementing the required C++11 library support. g++ chokes. > > Yep, the problem exists, the problem was found by testing, and the problem > needs to be fixed, but saying the problem is that libstdc++ uses C++11 > features > is silly. Suggesting that testing should be done before updating libc headers > is not condescending. Updating libc to use features supported by what? one, > maybe two compilers? and not even testing the latest version of GCC? that's > just sloppy engineering. Reporting failures caused by sloppy changes by > saying > "C++11 support should not be used during its own compilation step" is silly. I do not see how one can draw the conclusion that it is sloppy engineering, when an OS vendor writes code that is properly protected: #if defined(__cplusplus) && __cplusplus >= 201103L #define _Noreturn [[noreturn]] #endif Building libstdc++ is using -std=c++11 ... > If your issue is with the value of __cplusplus, that's not set by libstdc++, > so > I've set component=bootstrap. which is causing __cplusplus to become defined. This, then is, causing bootstrap to die in libstdc++ because the well-written code above has been decieved by the compiler.
