On Thursday, 19 December 2013 02:41:55 CEST, hero...@gentoo.org wrote:
I'd like to make an analogy to the version bump of gcc[1]. We (gentoo) decide to support c++11 officially or not. If so, open a tracker bug to push it globally. If not, patch lldb to support non-c++11, or leave it up to the user to fiddle with the CXXFLAGS, where we only point the user by to proper docs.
To be honest, I do not really see a link between the "let's bring in a new version of compiler, it is a bit stricter in some situations, but these were bugs anyway, like missing headers or unfounded assumptions about memcpy()" with "let's support a new version of language which produces object files with different ABI". Perhaps a Python 2.6 vs. Python 3.3 is a better analogy?
Anyway, GCC 4.8 is pretty clear that the C++11's support is still experimental [1] and subject to change [2]. The upstream developers have announced that they plan to break the ABI of the code using C++11 features in 4.9 [3].
Please also note that this is a very complicated problem, much more difficult than "code uses C++11's features -> it is incompatible". So far, the only known incompatibility is in the way STL is built. The impact of the other changes like the modified signatures of a couple of STL methods is not clear to me (and I did search for an ultimate answer). Even the document listing the breakage [4] does not provide a clear message "if you do $FOO, stuff breaks, but $BAR is completely safe".
For example, there is no reason for not building e.g. Qt5 with C++11 support. In fact, limiting it to use just the C++98 features would be considered a regression from the perspective of a developer using Qt.
Right now, it seems that we shall wait at least for GCC 4.9 to come and for upstream to decide how to solve this properly.
Cheers, Jan [1] http://gcc.gnu.org/gcc-4.8/cxx0x_status.html [2] https://lwn.net/Articles/552831/ [3] https://lwn.net/Articles/552750/ [4] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
