lib.systems.examples: Split glibc powerpc64 back into 2 ABI options

[OPNA2608]

ELFv1 is the historically better supported one on glibc, ELFv2 seems to have some issues with our toolchain.

Restore the option to pick the ABI with pkgsCross.

---

The split ABI options were initially introduced in 72b3bad, and removed again in 8ea1660 due to lack of support for specifying these ABIs via the config string. We have since gone back to specifying the ABI in the config string, so there shouldn't be any issue with bringing this back either.

Bootstrapping Nixpkgs on powerpc64 got stuck due to valgrind really not being happy with ELFv2 (#295906), so I'd like to try using the tried-and-tested ABI for this platform instead (eventually… this doesn't have a suuuuper high priority for me rn). This is a first step towards that.

---

72b3bad mentioned:

Many other platforms are moving to ELFv2 too, such as FreeBSD (as of v13) and Gentoo (as of late 2020).

• I believe FreeBSD did end up switching to ELFv2
• Gentoo I think still defaults to ELFv1, with ELFv2 labeled as a not supported option
  https://wiki.gentoo.org/wiki/Project:PowerPC#Key_facts

And to give some more examples:

• Debian is on glibc ELFv1, and I doubt that'll be changed anytime soon.
• Adélie Linux is on musl, so they need to use ELFv2. They use various patches to fix ELF 1 vs 2 issues.
• Void Linux used to have a glibc ELFv2 fork, but it was first scaled back due to lack of resources, and then ceased to be maintained altogether in favour of the musl ELFv2 distro Chimera Linux.

---

pkgsCross.ppc64-elfv1.hello builds (and runs) fine on my end.

CC @r-burns, as the author of the aforementioned two commits. Don't know if you still have an interest in big-endian powerpc64 and this ABI stuff.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (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, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

FWIW, I think full NixOS would require ELFv2, since we use static musl in load‐bearing components like setuid wrappers?

[OPNA2608]

FWIW, I think full NixOS would require ELFv2, since we use static musl in load‐bearing components like setuid wrappers?

AFAICT, a static ELFv2 musl wrapper for an ELFv1 glibc binary seems to work fine:

puna@HC ~> /nix/store/kiy6z5sdlc71chcnp46swzyj2vi27q5h-security-wrapper-sudo-powerpc64-unknown-linux-musl/bin/security-wrapper 
sudo: /nix/store/8gl2ixq55dzr30w6rcbh1snk1c252wij-sudo-powerpc64-unknown-linux-gnuabielfv1-1.9.16p2/bin/sudo must be owned by uid 0 and have the setuid bit set
puna@HC ~ [1]> file /nix/store/kiy6z5sdlc71chcnp46swzyj2vi27q5h-security-wrapper-sudo-powerpc64-unknown-linux-musl/bin/security-wrapper
/nix/store/kiy6z5sdlc71chcnp46swzyj2vi27q5h-security-wrapper-sudo-powerpc64-unknown-linux-musl/bin/security-wrapper: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), statically linked, with debug_info, not stripped
puna@HC ~> file /nix/store/8gl2ixq55dzr30w6rcbh1snk1c252wij-sudo-powerpc64-unknown-linux-gnuabielfv1-1.9.16p2/bin/sudo
/nix/store/8gl2ixq55dzr30w6rcbh1snk1c252wij-sudo-powerpc64-unknown-linux-gnuabielfv1-1.9.16p2/bin/sudo: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, Power ELF V1 ABI, version 1 (SYSV), dynamically linked, interpreter /nix/store/9qzl96v65k491szpkvp4g58idjjhm6qw-glibc-powerpc64-unknown-linux-gnuabielfv1-2.40-66/lib/ld64.so.1, for GNU/Linux 3.10.0, not stripped

(The instructions for testing the security wrapper stuff here don't seem to work anymore as-is, btw)

Magical incantation that worked for me (after applying some fix so ncurses is happy):

↪ nix-build -E '
  with import ./. {
    crossSystem = "powerpc64-unknown-linux-gnuabielfv1";
  };

  let
    # Copied from nixos/modules/security/wrappers/default.nix
    unsecvars = lib.overrideDerivation (pkgs.srcOnly pkgs.glibc) (
      { name, ... }:
      {
        name = "${name}-unsecvars";
        installPhase = \'\'
          mkdir $out
          cp sysdeps/generic/unsecvars.h $out
        \'\';
      }
    );
  in
  pkgs.pkgsStatic.callPackage ./nixos/modules/security/wrappers/wrapper.nix {
    sourceProg = "${lib.getExe pkgs.sudo}";
    debug = true;
    inherit unsecvars;
  }'

[emilazy]

Makes sense; I just wasn’t sure if the toolchain issues were serious enough to make mixing and matching like that as difficult as using ELFv2 entirely.

[r-burns]

Looks reasonable to me - it seemed that musl was the big motivator for moving to elfv2 but if the static musl wrapper works OK then that seems like a good workaround. No strong opinions here so I'm fine with defaulting to whatever seems most stable, and restoring the ability to pick from either option again seems nice.