treewide: Fix Meson CPU names for powerpc CPUs

[OPNA2608]

(Still building on my machine, will undraft when it finishes & builtins.currentSystem returns the correct value)

Motivation

Meson's cpu_family() function returns ppc* on POWER systems, while Nixpkgs expects the previously-used powerpc* to be the CPU name:

puna@HC ~/D/nixpkgs (wip/ppc64-elfv1)> nix repl --file .
Nix 2.28.4
Type :? for help.
error:
       … while evaluating a branch condition
         at /home/puna/Development/nixpkgs/pkgs/stdenv/booter.nix:68:9:
           67|         pred: n:
           68|         if n == len then
             |         ^
           69|           rnul pred

       … while calling the 'length' builtin
         at /home/puna/Development/nixpkgs/pkgs/stdenv/booter.nix:65:13:
           64|     let
           65|       len = builtins.length list;
             |             ^
           66|       go =

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: Unknown CPU type: ppc64

Fix this discrepancy.

Context

Closes #12769

No real experience with Meson, so happy about better-looking suggestions.

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[OPNA2608]

Gives me lots of errors like this when trying to run the tests:

this derivation will be built:
  /build/nix-test/main/optimise-store/store/v3f4rsnzwic866sr81m41x3jzzdzxbmh-foo1.drv
error: a 'ppc64-linux' with features {} is required to build '/build/nix-test/main/optimise-store/store/v3f4rsnzwic866sr81m41x3jzzdzxbmh-foo1.drv', but I am a 'powerpc64-linux' with features {benchmark, big-parallel, nixos-test, uid-range}

So this call prolly also needs to be fixed:

nix/tests/functional/meson.build

Line 33 in 6ec50ba

'system': host_machine.cpu_family() + '-' + host_machine.system(),

I assume I can just move default_nix_local_system_cpu to a higher-level meson.build and reference it in multiple lower-level places, so I'll try that.

Edit: Well, this turned out abit is less pretty than I was hoping…

[OPNA2608]

Oh, do the subprojects get built directly without going through the main meson.build as well? Hmm… Copy-pasting it is then :s.

[xokdvium]

@OPNA2608, which nixpkgs revision and what powerpc target triple can I use to build this? Are you using cross?

[OPNA2608]

I'm working on bootstrapping ELFv1 ppc64 & fixing big-endian and ABI issues with packages. I have this branch in my Nixpkgs fork with all my changes so far applied so I can continue testing builds while changes slowly work their way into Nixpkgs.

I'm currently on OPNA2608/nixpkgs@c879d60 using the ppc64-elfv1 config in lib.systems.examples - which is powerpc64-unknown-linux-gnuabielfv1. Using just powerpc64-linux will currently go with the ELFv2 ABI which might work as well, though I haven't really tested it.

I'm using an old POWER machine, so not cross. I had to cross-compiled a Nix installer from x86_64 a long while ago, everything else has been built natively.

[xokdvium]

ELFv2 ABI which might work as well

Openssl cross doesn't seem to work there. I'll give your branch a shot for cross, but it's a pretty huge rebuild.

With these changes nix builds (modulo AWS) and tests pass on powerpc64-unknown-linux-gnuabielfv1 natively for you, right?

[xokdvium]

Alright, so with your branch I was able to build cross nix with the patch:

diff --git a/flake.nix b/flake.nix
index 2b93429e9..c08a5f5fe 100644
--- a/flake.nix
+++ b/flake.nix
@@ -54,6 +54,7 @@
         # "x86_64-unknown-netbsd"
         "x86_64-unknown-freebsd"
         "x86_64-w64-mingw32"
+        "powerpc64-unknown-linux-gnuabielfv1"
       ];
 
       stdenvs = [

And your original command works:

nix build .\#nix-cli-powerpc64-unknown-linux-gnuabielfv1 -L --override-input nixpkgs github:OPNA2608/nixpkgs/c879d608e311bf02b06b62b96f89bb6cbb53386d
qemu-ppc64 result/bin/nix eval --file ../nixpkgs hello

[OPNA2608]

nix builds (modulo AWS) and tests pass on powerpc64-unknown-linux-gnuabielfv1 natively for you, right?

One of the earlier iterations previously built with passing tests. Currently checking the latest one juuust to make sure, but I think the previous one just had the obsolete default_nix_local_system_cpu block, so I expect it to still be passing.

[OPNA2608]

checking for references to /build/ in /nix/store/rc7jxky02ps4gp8bfv9xk7jmqvpjx9gh-nix-2.28.4-doc...
patching script interpreter paths in /nix/store/rc7jxky02ps4gp8bfv9xk7jmqvpjx9gh-nix-2.28.4-doc
/nix/store/lss2pmn2ilvypz28mnfkpsxxzl43a368-nix-2.28.4
puna@HC ~/D/nixpkgs (wip/ppc64-elfv1)> /nix/store/lss2pmn2ilvypz28mnfkpsxxzl43a368-nix-2.28.4/bin/nix-instantiate --eval --strict --expr 'builtins.currentSystem'
"powerpc64-linux"
puna@HC ~/D/nixpkgs (wip/ppc64-elfv1)>

Seems fine!

[xokdvium]

Seems fine!

Thanks @OPNA2608. I'll backport this up to 2.28, so that the default nix version in nixpkgs has this fix.

[xokdvium]

Argh, I didn't look at the meson docs hard enough. ppcle isn't a thing there, you'd need to check the .endian(). This should be correct #13520.

[OPNA2608]

ppcle isn't a thing there, you'd need to check the .endian().

So funny thing: In Nixpkgs, under cross, it actually is a thing. I imagine due to a similar misunderstanding of these details (or just lack of interest/testing).

https://github.com/NixOS/nixpkgs/blob/bec36361e29d8512853ee488fbccc6874a395200/pkgs/build-support/lib/meson.nix#L6-L15

When targeting POWER via cross, the cross file for Meson will be set up to use stdenv.hostPlatform.uname.processor. So:

puna@Carlos:~/Development/nixpkgs
↪ nix-instantiate --eval --strict --expr 'with import ./. { crossSystem = "powerpcle-linux"; }; stdenv.hostPlatform.uname.processor'
"ppcle"

puna@Carlos:~/Development/nixpkgs
↪ nix-instantiate --eval --strict --expr 'with import ./. { crossSystem = "powerpc64le-linux"; }; stdenv.hostPlatform.uname.processor'
"ppc64le"

Oops! I'll submit a PR there to add special handling for POWER targets.

[xokdvium]

Ah this is a mess. Funny thing is that MIPS does the right thing in nixpkgs.