These configurations break enough that I doubt anybody is depending on
them. I think I would have seen more bug reports if people were trying to
use it.
This is also the entirely wrong question to ask. What's important is that
Libc++ is allowed to required C++11, and C++11 implementation should work.
People who insist on using a ToT STL with an old compiler puzzle me. You
can't expect new library features without additional language support.
/Eric
I think we have found consensus, or at least mild agreement, that nobody needs libc++ to support GCC 4.6, 4.7 or 4.8.
Unless there are any late objections I’m going to proceed with
While GCC 4.9 may not be optimal for everybody it is a compiler we can meaningfully support.
Users of GCC 4.9+ should expect no test failures in C++11 mode and I will set up a buildbot to enforce this.
This new requirement also has an exciting implication: Libc++ no longer has to configure for incomplete C++11 implementations.**
This means that libc++ no longer has to restrict its use of C++11 features such as “constexpr” and alias templates in C++11 mode.
However I still don’t know what to do about GCC in C++03 mode, which still has over 600 test failures. But that is a separate
question and deserves it’s separate thread. Expect to see a new thread in cfe-dev tonight.
/Eric
** I’ll triple check this before I act on it.
FWIW, for the few users I support who care about C++03 mode, it would actually be a significant feature to turn off all C++11 emulation in libc++ and to present as close to a pure C++03 environment as possible. Those users have some environments they support which are functionally C++03 and they are setting the C++03 mode to try and detect problems sooner when building and testing with the nice modern Clang+libc++ (or GCC+libc++) toolchain they have in their main development environment. I wonder if ceasing to emulate so much of C++11 library features (and language features!!! nullptr for example!) when building in C++03 would help with this.
Relatedly, I think you could require a C++11 implementation to build libc++ itself and merely support C++03 parsing of the headers (and subsequent linking of that object code with the library). That might allow you to maintain a single ABI of the built library even as you switch between C++03 and C++11 usage of the library.
This is the status-quo. You have always needed C++11 to build libc++ and dylib produced is ABI compatible between Clang C++03/C++11 and GCC C++11.
GCC in C++03 doesn’t provide char16_t and char32_t and this causes link errors in locale code.