stdenv: use gcc11 for riscv

[NickCao]

Description of changes

An increasing number of riscv packages are requiring gcc11 to build likely due to the binutils update to 2.38. And I'm seeing little regression with this change on my hydra apart from gccForLibs which looks like a upstream issue.
ref: #168826

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[NickCao]

For the gcc issue: see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
Edit: should be fixed by #170121

[Madouura]

Considering it's the same change I am using in my PR, and I have a working riscv64 system on hardware with this change, I'd have to say LGTM.

[r-burns]

To be honest I think the original gcc 10 -> 11 bump should have just changed it to else 11 instead of adding yet another special case.

[NickCao]

To be honest I think the original gcc 10 -> 11 bump should have just changed it to else 11 instead of adding yet another special case.

What's the situation now for gcc11 on aarch64?

[r-burns]

Not sure, don't have aarch64 hardware but I'll request access to the community builder. Would be great to get all our tier 1-3 platforms on the same gcc version.

[fabianhjr]

What's the situation now for gcc11 on aarch64?

aarch64-linux is borked on gcc10 and gcc11 afaik and it was recently tested. (Silghtly after the proposed 10 → 11 for x86_64-linux)

Though, no aarch64 hardware on my end.

[fabianhjr]

Not sure, don't have aarch64 hardware but I'll request access to the community builder. Would be great to get all our tier 1-3 platforms on the same gcc version.

To be honest I think the original gcc 10 -> 11 bump should have just changed it to else 11 instead of adding yet another special case.

I was hoping other contributors in other platforms would help with those bumps since there was risk of breakage on platforms I didn't have access to nor would have been able to help with. (mainly tier2, x86_64-darwin and aarch64-{darwin,linux}).

Here is the current RFC0046 tiers 1-3:

Tier 1

• x86_64-linux, gcc+glibc

Tier 2

• aarch64-linux, gcc+glibc
• x86_64-darwin, clang+Darwin/macOS

Tier 3

• i686-linux, gcc+glibc — ofBorg builds via pkgsi686Linux, binary cache contains wine dependencies
• armv{6,7,8}*-linux, gcc+glibc
• armv{6,7,8}*-linux, gcc+glibc, cross-compilation
• aarch64-linux, gcc+glibc, cross-compilation
• mipsel-linux, gcc+glibc
• x86_64-linux, gcc+musl

Need testing/bump to gcc11:

• aarch64-linux, gcc+glibc
• aarch64-linux, gcc+glibc, cross-compilation
• i686-linux, gcc+glibc
• armv{6,7,8}*-linux, gcc+glibc
• armv{6,7,8}*-linux, gcc+glibc, cross-compilation
• mipsel-linux, gcc+glibc

[tpwrules]

This is the PR about gcc11 on aarch64: #167726

This is the latest effort and problem I know about, but I'm not knowledgeable enough to try and fix it. I have fairly powerful aarch64 hardware, so if someone wants me to test a fix I would be happy to. I am very in favor of everything being on gcc11.

[vcunat]

Also, (a dependency of) wine won't build if the default is switched.

[Madouura]

Also, (a dependency of) wine won't build if the default is switched.

I think we may want to treat that as a special case and use GCC 10 in the all-packages.nix entry, or devise a patch per-case for cases like that.

[vcunat]

Perhaps. The difference is in platforms that noone's tried yet (and specified explicitly there). No idea if the change will help them or harm them. I'd probably leave the default be for 22.05 for those reasons.

[Madouura]

I agree, 22.05 is meant to be stable, and is already too late-stage for a change in default stdenv for tier-1 platforms, no reason to fix what's not broken for a release.
For future releases though, I do think it would be appropriate to default to GCC 11, or perhaps 12 if it's out by then.

[trofi]

If wine build breakage is related to mingw32-gcc patchset then proposed #171147 should fix it.