stdenv: add pure Linux stdenv support for powerpc64le and sparc64

[piperswe]

Motivation for this change

I have a sparc64 system I want to try to get NixOS running on, and if I can get NixOS working well in a powerpc64le emulator, I'll consider getting a ppc64le server to play around with (and probably use as a Hydra buildbox so I can add ppc64le to my binary cache).

I've been building things for this branch on my Hydra instance as part of my nixfiles project/jobset: https://hydra.piperswe.me/jobset/nixfiles/main

The results of basically all of my builds go into my binary cache, so if you want to play around with this branch you can use my binary cache to speed things up:

{
  nix = {
    binaryCaches = [
      "https://nix-cache.piperswe.me"
    ];
    binaryCachePublicKeys = [
      "nix-cache.piperswe.me:4r7vyJJ/0riN8ILB+YhSCnYeynvxOeZXNsPNV4Fn8mE="
    ];
  };
}

Since changing stdenv requires rebuilding the world, I might also add a few more interesting architectures to this PR so that we have bootstrap tools for most architectures out there at the cost of one world rebuild.

Fixes #113977. Depends on #141451.

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 via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 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
• Fits CONTRIBUTING.md.

[r-burns]

Cool, I'm glad there are others interested in exotic platforms. Feel free to ping me for review on any related PRs.

W.r.t. bootstrap tools, see also #115406. These always get held up because it's hard to verify that the bootstrap tools are reproducible - how do you do that for native bootstrap tools on a platform we don't support yet? But on the other hand, cross-compiled bootstrap tools won't build stdenv because of #113977, so I'm not really sure how to proceed here.

Your first commit (b8eebed) looks pretty noncontroversial, if you'd like to split that off into a separate PR we could probably get that merged quickly and start playing around with cross-compiled sparc64 packages.

[piperswe]

W.r.t. bootstrap tools, see also #115406. These always get held up because it's hard to verify that the bootstrap tools are reproducible - how do you do that for native bootstrap tools on a platform we don't support yet? But on the other hand, cross-compiled bootstrap tools won't build stdenv because of #113977, so I'm not really sure how to proceed here.

Very true... it seems like there are three stages to building bootstrap tools:

1. Cross-compile
2. Native using cross tools
3. Native using native tools

Maybe there should be more automation around building these - like, on a system with qemu-binfmt, you have a derivation that runs through all three stages, though that requires having a way to inject the newly built bootstrap tools into nixpkgs.

The first approach that comes to mind would be adding an argument to nixpkgsFun for the seeds, which probably wouldn't be a bad idea in general. I'd love to hear other people's thoughts on that though.

[piperswe]

See #113977 / #113977 (comment)

[SuperSandro2000]

This is basically platforms.linux? Or which platform is not supported? I can't tell. It would be way cleaner to substract the one or two not working platforms from platforms.linux or just write them into meta.broken.

[SuperSandro2000]

Why do we suddenly need to accept any input here and in the other files below? I don't think that is a good idea because it swallows mistakes like typos and makes.

[SuperSandro2000]

This and the 3 files below are very similar. Could we combine them?

[SuperSandro2000]

That could break with flakes because currentSystem is not defined there.

[SuperSandro2000]

Suggested change

	stageSuffix = if stage == null then "" else "-${stage}";
	stageSuffix = lib.optionalString (stage != null) "-${stage}";

[SuperSandro2000]

Suggested change

	systemSuffix =
	if crossSystem == null
	then "-${localSystem.system}"
	else "-${localSystem.system}-to-${crossSystem.system}";
	systemSuffix = "-${localSystem.system}" + lib.optionalString (crossSystem != null) "-to-${crossSystem.system}";