GCC 5 in Fedora
developerblog.redhat.com
developerblog.redhat.com
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?
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).
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.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
So I'll have to disable asan or convince llvm to accept davm's patches and then wait for gcc to merge from upstream.
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.
Usually, my laptop can recompile @world (aka everything) overnight, so it's not too much of an issue.
Had to check the date, we are not yet in April.