[WIP] Switch to gcc 5

[shlevy]

No description provided.

[edolstra]

I don't think we should switch to GCC 5 at this point. It seems way too early. I mean, it was released two weeks ago...

[shlevy]

Any reason I can't start testing?

[shlevy]

Jobset here http://hydra.nixos.org/jobset/nixpkgs/gcc-5

[edolstra]

I'd rather spend hydra.nixos.org resources testing 4.9. Unfortunately it's pretty overloaded lately :-(

[shlevy]

That seems strange to me. It's one thing if we find seriously insurmountable problems with gcc 5, but if we're taking the hit of a gcc upgrade anyway why not get the ABI issues over with and get the benefit of all the new features and bug fixes?

[edolstra]

With GCC 5 you also get the "benefit" of all the new bugs :-)

GCC 4.9 has been out for a year, so it's likely to be more stable than 5.1, and most package breakage will have been fixed in the meantime. It also doesn't involve an ABI change so it should be a fairly uncomplicated update.

But I just noticed you're using release-small.nix, so I have no problem with building it on Hydra. (Main problem lately is disk space, but a small release shouldn't eat up much...)

[shlevy]

OK, cool. Any way the community can contribute to more disk space?

[vcunat]

The C++ ABI change shouldn't be a problem, IMHO. As explained, the old ABI is kept with the old linking names, and a new one is added. You choose by #defining a macro, so we could even make it use the old ABI by default, but I don't see a reason for that.

In the docs on changes for both 4.9 and 5, I don't see anything likely to cause larger problems, but OTOH undiscovered-bug potential seems hard to predict.

[edolstra]

Libstdc++ may be dual-ABI, but that doesn't apply to other packages. So if you have a package that requires GCC 4, you need to build a separate copy of every C++ dependency (like Boost) with the old ABI.

[shlevy]

Yes, we will either need to drop support for old gcc versions or force th old ABI everywhere

[vcunat]

ATM I can only see three packages referring gcc older than our current (4.8), so the possibility of many packages needing dual build seems very unlikely to me.

[edolstra]

GCC 5 is now in staging (dd53c65).