> It seems to be an inadvertent incompatibility caused by the > interaction of a libstdc++ workaround for a bug and g++ behaviour that > may not have been known to the libstdc++ devs, so not something that > could have been prevented by making it a linker error, because noone > knew it was even broken. Testing and reporting bugs and analysing the > problem should lead to it being fixed. I think the problem was GCC > devs not knowing the problem existed, rather than not taking it > seriously.
Whether or not this particular incompatibility was intended or not, the point remains. You cannot say that GCC devs are taking the C++11 binary incompatibility issue seriously while: a) there exist serious ABI incompatibilities between the modes. b) there is essentially no notice to users about the problem (and lots of users already brokenly compiling in C++11 mode!) c) there are no recommendations or plans for how users and distros are expected to deal with the issue. I am happy to see that Matthias has also recently noted this issue from the point of view of a distribution. But I'm *quite* surprised to see that even now it is apparently a surprise to some on this very list that there is such an incompatibility! When I noted the std::list incompatibility back last October when it was introduced (on http://gcc.gnu.org/PR49561), the response was quite clear that there is no expectation of compatibility between the modes, and never was. When I tried to ask some of these same questions last November (in the "Long-term plan for C++98/C++11 incompatibility" thread), the answer I heard there seemed to me to be ~"distros should just provide two sets of libraries, not our problem". IMO, at the /very least/, libstdc++ should go ahead and change std::string to be the new implementation. Once std::string is ABI-incompatible between the modes, there's basically no chance that anyone would think that linking things together from the two modes is a good thing to try, for more than a couple minutes.
