Closed edolstra closed 6 years ago
GCC 6 is then going to be part of 17.09?
I'm willing to help with the GCC 6 and/or GCC 7 effort. Currently testing a rebuild of my desktop and laptop configurations with a local merge of the gcc-6 branch and master.
I tried the GCC 7 branch yesterday and managed to patch a few projects to get them to compile, however, the ruby executable compiled by gcc 7.1 seemed to segfault when used to build another package. (can get more details if wanted)
@NeQuissimus no, not in scope sadly.
For fixes please PR to the gcc-7 branch
Fedora tests didn't show a mass failure, so it might be easier than the step to 6.x. I can see a potential catch: some C++ operators change ABI between 6.x and 7.x, so the usual trick of switching some individual packages to older gcc might not always work anymore.
In fact gcc 6 also broke ABI compatibility with the code generated by gcc 5: the latter had a bug when abi_tag was not propagated into templates. gcc 6 fixed it, and this changed name mangling.
I can imagine that implementing a C++ compiler is a nightmare.
I spent some time on this now, fixing the larger failures, and it starts looking reasonable. We now have binaries for most x86_64-linux packages and aarch64-linux is in progress now, so feel free to join testing and fixing. I might merge to master during the next weekend.
There will still be hundreds of individual failures, but I can't afford to spend time fixing everything myself, and my experience is (unfortunately) that it's not easy to get participation from more than a couple people before merging the failures to master...
Most of the failures are caused by new warnings for packages that explicitly force warnings into errors, and these are easy to work around by ignoring those warnings.
I'd prefer if we fix the remaining breakage from the glibc upgrade before upgrading gcc.
I've identified the remaining glibc breakage in #31696, next I'll look into what will break due to gcc 7.
Currently there are still many jobs regressing on the gcc-7 branch – on the order of one thousand. I agree it will be better to take the merging a bit slower.
Well, I except participation will be pretty low without proper visibility on what actually is broken, i.e. we need a similar generated list of failures like we do for ZHFs: https://github.com/NixOS/nixpkgs/issues/29221.
I don't think the built-in script in nixpkgs is capable of doing a diff between evaluations but I can take my ugly parse-HTML-with-grep-and-xmllint scripts one and produce one, provided that someone arranges two evaluations from both trunk/staging and gcc-7 where the base commit is the same.
Hydra has a "Compare to" feature that shows regressions between jobsets. Unfortunately it doesn't work here because the gcc-7 jobset is in the wrong project (it should be in nixpkgs rather than nixos).
Sure, but that's still an extra link to click, you don't get those checkboxes to tick off fixed things, or the ability to write comments (like the maintainer ping) next to it.
Last call! (before merging to master) See https://github.com/NixOS/nixpkgs/issues/31747#issuecomment-366555928
There is no particular ETA for this, but it might be nice for NixOS 18.03.
Hydra jobset is here: https://hydra.nixos.org/jobset/nixos/gcc-7