This gives me a strange impression of deja vu ... oh right, RedHat Linux and the not-quite-standard gcc 2.96 version and the solution of having a separate "kgcc" program that you could use to compile the programs that the default gcc broke. I feel slightly old now.
The article does seem to imply that they want to ship the new gcc but keep using the old ABI for a while to keep things compatible. Did I read that right?
Both ABIs are shipped in libstdc++, but all other libraries are build with the old ABIs.
You can manually use the libstdc++ with the new ABI, but any of your dependencies that use the problematic ABI must then be rebuild (and will be in F23).
Anyone know about LLVM and their plans? The reason I ask is that I'm starting to do some Rust code and one of the nice features is that they use C++ name mangling. I'm guessing I shouldn't assume that there will be interoperation with installed C++ libraries in the short-mid term :-(.
LLVM does not need to worry about compatibility here because its libc++ is relatively new and was designed with C++11 requirements in mind, whereas GNU libstdc++ is >20 years old and could not possibly have anticipated these new requirements.
OTOH on Linux you're most likely using clang together with libstdc++, and whether that would use old or new ABI would depend on whether the magic macro is defined in libstdc++ or by g++.
The article says "the C++ standard library headers installed by the libstdc++-devel RPM will have a different default value for the _GLIBCXX_USE_CXX11_ABI macro" so that sounds like clang should do the same thing as g++ here.
Note that even though Rust does name mangling, it does not necessarily mangle names exactly as C++ does (and different C++ compilers on different platforms may already differ on how they perform mangling, it's not standardized).
One of fedora's key values is to be leading the way on stuff like this, so it's not surprising that other major distros aren't quite caught up just yet[0] (although I think for this particular one, debian won't be far behind).
That said, I do wonder if this change is going to break more things for end users than they really bargained for. It reminds me a little of the Pulseaudio introduction - where in the haste to ship the new shiny ASAP, they ended up shipping a distro where a huge percentage of users never really got properly working sound.
In this case, I'm worried that they underestimate the amount of stuff that users depend on but aren't included in the distro, and that many of these will break. Thinking of stuff like dropbox, the nvidia drivers, skype, etc.
I'm not certain that in retrospect this will be shown to be one of FESCo's better rulings, and that they would have done better to give companies like nvidia, microsoft and dropbox more time to adapt. But time will tell.
Debian has gcc-5 in experimental. A fact I'm taking advantage of because I want to get Docker working on my sparc server but gccgo is broken on 4.9.
It was fixed a few months ago in the gcc repository but the bleeding edge gcc repo has a broken libsanitizer on sparc. David Miller made some patches but gcc won't accept them(has to go through upstream) and upstream(llvm) have been ignoring them.
I think the parent's comment was about using GCC5 to compile all the distro's packages, not just providing GCC5 for its users. The Fedora article is unclear about what they mean, but the consequences they refer to imply using GCC5 to compile their packages.
As far as I know, while your link shows that Debian is getting ready to provide it to its users, they haven't yet formed plans to use it to compile their packages.
Not yet - gcc (GCC) 4.9.2 20150204 (prerelease)
But the article reasoning of having to stick it out for a long time doesn't apply anyway when you have a rolling release.
They're shipping gcc 5, but configures it to use a C++ ABI compatible with older gcc versions, for reasons that does not have anything to do with "they can't even build their distribution with it".
The article does seem to imply that they want to ship the new gcc but keep using the old ABI for a while to keep things compatible. Did I read that right?