[WIP] Make GCC 5.x the default

[wkennington]

Using the changes in staging / master, we should be able to start isolating the remaining problems breaking adoption of gcc5. I already maintain my own branch which has defaulted to gcc5 for a while so a lot of major kinks have already been worked out. Please test the changes in staging.post-15.06 if you would like to help the effort of getting nixpkgs ready for gcc5. The migration should be easiest if we mainline transition patches into master / staging where appropriate, as they have been entirely backward compatible with the old compiler. Merging the patches into mainline should reduce the effort of keeping a separate branch, as the branch is just the switch to gcc5.

[wkennington]

Currently blocking is a known bug with syslinux 6.03 which prevents getting past the initial isolinux splash on the livecd in bios mode. This should be testable using nix-build nixos/release.nix -A tests.bootBiosCdrom.x86_64-linux

[vcunat]

/cc #7807.

[domenkozar]

Not sure this should be a blocker

[vcunat]

Blocker for the 16.xx release? Status of that doesn't seem important ATM.

[edolstra]

Sounds like a good way to mark major desired features of the new release. The "blocker" status can always be removed, of course.

However, before we make GCC 5 the default, we should decide what to do about the C++ ABI issue. I would suggest setting _GLIBCXX_USE_CXX11_ABI to 0 by default for now to minimize incompatibilities. (I think Fedora 22 did this as well.)

[wkennington]

Got an example of what not dealing with the abi change breaks? I've been
using gcc5 for a while with no issues. Or is this the same as the -std
setting?

On Mon, Aug 31, 2015, 02:32 Eelco Dolstra notifications@github.com wrote:

Sounds like a good way to mark major desired features of the new release.
The "blocker" status can always be removed, of course.

However, before we make GCC 5 the default, we should decide what to do
about the C++ ABI issue. I would suggest setting _GLIBCXX_USE_CXX11_ABI to
0 by default for now to minimize incompatibilities. (I think Fedora 22 did
this as well.)

—
Reply to this email directly or view it on GitHub
#8729 (comment).

[edolstra]

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html.

[vcunat]

the choice of ABI to use is independent of the -std option used to compile your code

I believe for any decent packages the problems will be build-time only, i.e. Hydra will discover them and then we can decide. (Well, I hope no packages depend on implementation details that weren't guaranteed by C++ standard.)

Note that Fedora's main reasoning to keep the old ABI was that they didn't have enough time for a mass rebuild :-D http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/

[wkennington]

I see no reason to disable this in nix given that they promise old binaries
will still work, and new source compiles will use the new implementation of
functions which conform go the c++11 spec. As far as I know the changes do
not affect visible behavior so much as expected underlying behavior.
Therefore the only thing we actually lose is the ability for our binaries
to use an old libstdc++, which shouldn't be a problem in nix.

On Mon, Aug 31, 2015, 09:30 Eelco Dolstra notifications@github.com wrote:

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html.

—
Reply to this email directly or view it on GitHub
#8729 (comment).

[vcunat]

Well, the cooperation between packages using different ABI can be a problem, e.g. passing the affected containers (std::string implementation changes). Theoretically, if one is inconsistent, e.g. when using gstreamer plugins or similar dynamic mechanism where we don't always enforce they're built from the same nixpkgs version...

[edolstra]

@wkennington No, it's also an issue in Nix. For instance, if you link together libraries compiled with GCC 4 and with GCC 5.

[wkennington]

I can't imagine there will be more than a handful of cases like this, we
should do a test run and see what we get out of it. The only special cases
I've had to make so far were syslinux, which isn't c++, and v8 which
doesn't expose an interface that uses these c++ classes.

On Mon, Aug 31, 2015, 10:37 Eelco Dolstra notifications@github.com wrote:

@wkennington https://github.com/wkennington No, it's also an issue in
Nix. For instance, if you link together libraries compiled with GCC 4 and
with GCC 5.

—
Reply to this email directly or view it on GitHub
#8729 (comment).

[heydojo]

ati-drivers will not compile using gcc5 at the moment. Ubuntu had to patch their package to force compilation with gcc4 https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1493888/comments/215.
So ati-drivers will need to depend on gcc49 instead of gcc5 until it is fixed.
ati_drivers_x11 = callPackage ../os-specific/linux/ati-drivers { stdenv = overrideCC stdenv gcc49; };
in all-packages.nix would do it?

[vcunat]

Yes, I believe that would solve it.

[domenkozar]

Relevant: #8962

[edolstra]

GCC 5 is now in staging (dd53c65).