Dnia 2013-12-19, o godz. 09:43:40 Jan Kundrát <[email protected]> napisał(a):
> On Thursday, 19 December 2013 02:41:55 CEST, [email protected] 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? Well, it's even worse than that. I think the main difference is that usual gcc/whatever bumps may have resulted in *one* different libstdc++ ABI. People rebuilt all their packages, world went back to normal. The issue here is that gcc is providing two ABIs in parallel, with a -std= switch. And this sucks pretty much... > 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]. Would it be possible to have a consistent ABI for both C++03 and C++11? The simpler changes like adding new fields can be backported quite easily (even if it would mean having dummy fields in C++03), I have no idea about the more complex changes. > 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. Well, if they considered the C++11 ABI in gcc-4.9 stable, we could consider changing the default to C++11. Then, we could do our bump/switch thing as a matter of gcc-4.9 upgrade problem. And that brings another issue in Gentoo -- gcc-config. AFAIR this tool is completely insane and switches libstdc++ along with gcc version. As a result, after switching to a gcc version with different C++ ABI, installed software gets broken. And you can't really fix it without going through the broken-system state or some hackery. It would be much better if the switching was done by some ebuild. We could then use subslots to force rebuilds of stuff using libstdc++. Well, more than that, preserved-libs would prevent disappearing old libstdc++ from breaking stuff. But well, that's just my wishes... -- Best regards, Michał Górny
signature.asc
Description: PGP signature
