kexec-tools: Only force ELFv2 on ppc64 when the platform settings aggree

[OPNA2608]

Fixes building for ELFv1.

gcc -fno-zero-initialized-in-bss -m64 -msoft-float -fno-exceptions -mabi=elfv2 -Os -fno-builtin -ffreestanding -fno-zero-initialized-in-bss -fno-PIC -fno-PIE -fno-stack-protector -fno-tree-vectorize -m64 -msoft-float -fno-exceptions -mabi=elfv2 -I./purgatory/include -I./purgatory/arch/ppc64/include -I./util_lib/include -I./include -Iinclude -I/nix/store/4x3b5aqamqsjm7z43z4ri6cajdban5dw-gcc-14.3.0/lib/gcc/powerpc64-unknown-linux-gnuabielfv1/14.3.0/include  -c -MD -o purgatory/purgatory.o purgatory/purgatory.c
In file included from /nix/store/zdsdr1j59by3ab1ryvqkx5kpdz30g7k2-glibc-2.40-66-dev/include/features.h:535,
                 from /nix/store/zdsdr1j59by3ab1ryvqkx5kpdz30g7k2-glibc-2.40-66-dev/include/bits/libc-header-start.h:33,
                 from /nix/store/zdsdr1j59by3ab1ryvqkx5kpdz30g7k2-glibc-2.40-66-dev/include/limits.h:26,
                 from /nix/store/4x3b5aqamqsjm7z43z4ri6cajdban5dw-gcc-14.3.0/lib/gcc/powerpc64-unknown-linux-gnuabielfv1/14.3.0/include/limits.h:210,
                 from /nix/store/4x3b5aqamqsjm7z43z4ri6cajdban5dw-gcc-14.3.0/lib/gcc/powerpc64-unknown-linux-gnuabielfv1/14.3.0/include/syslimits.h:7,
                 from /nix/store/4x3b5aqamqsjm7z43z4ri6cajdban5dw-gcc-14.3.0/lib/gcc/powerpc64-unknown-linux-gnuabielfv1/14.3.0/include/limits.h:34,
                 from purgatory/purgatory.c:2:
/nix/store/zdsdr1j59by3ab1ryvqkx5kpdz30g7k2-glibc-2.40-66-dev/include/gnu/stubs.h:14:11: fatal error: gnu/stubs-64-v2.h: No such file or directory
   14 | # include <gnu/stubs-64-v2.h>
      |           ^~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:123: purgatory/purgatory.o] Error 1

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
  • powerpc64-linux (ELFv1)
• 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 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 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.

[SuperSandro2000]

Do we need to make the patch optional? The next person updating the package might easily miss this to the disadvantage of powerpc users.

[OPNA2608]

With this patch file? Yes, because it breaks building for ELFv1 (which, eventually, I'm planning to make our default ABI on powerpc64, because it's less effort to get it to work properly). Doing this in a way that supports both ABI would require a custom patch, because upstream currently doesn't support different flags for different ABI targets.

[flokli]

We usually don't do conditional patches, because they end up breaking easily without being noticed during regular package bumps.

We're less strict for more "exotic" targets/platforms, see this example:

nixpkgs/pkgs/os-specific/linux/systemd/default.nix

Line 257 in 349024c

++ lib.optionals stdenv.hostPlatform.isMusl (

I think it's fine to pull it in conditionally, cause power64 is also somewhat niche, but I strongly recommend to start upstreaming this in a more generic fashion to avoid this breaking in the future.

[flokli]

Yes, because it breaks building for ELFv1 (which, eventually, I'm planning to make our default ABI on powerpc64, because it's less effort to get it to work properly).

Isn't elfv1 marked as legacy? (see rust-lang/rust#60617)

[OPNA2608]

ELFv1 is considered legacy, but big-endian 64-bit POWER itself is kind of legacy too. Modern 64-bit POWER processors are usually run in little-endian mode, where ELFv2 is (IIRC) the only supported ABI. But 64-bit POWER started out as big-endian in Linux, ELFv1 was the current version for most of its lifetime, and glibc still defaults to ELFv1 unless explicitly told otherwise, so it's still the "default".

The ABI situation of powerpc64 in the libc's is as follows:

• glibc supports either ABI version, but defaults to ELFv1 unless specifically told otherwise
• musl only supports ELFv2

Certain (bad) assumptions have developed like ~ "on 64-bit POWER, the ABI is ELFv2 on LE and ELFv1 on BE". Patches like the one that gets shuffled around in this PR come mostly from musl-running distros - Void PPC when it was still around, Adelie Linux, Chimera Linux are all musl distros that I used to look towards for ELFv2 patches. All glibc-using distros supported powerpc64 that I could find (Debian, Gentoo) use the ELFv1 ABI that glibc defaults to. Some (Gentoo IIRC) attempted to switch their glibc to ELFv2 in the past, but it looks like they're still on ELFv1 as of today.

I gave up on ELFv2 when I got to Valgrind. I was unable to get it to accept & properly handle ELFv2 binaries produced by Nix, unless I built them against musl and used patchelf to replace our musl in the final binary with i.e. Adelie's musl. So either something is missing in the ELFv2 patch, or our toolchain just uniquely breaks Valgrind. The ELFv2 MR has been dormant for awhile upstream, so I'm not too optimistic about this support becoming official soon. In contrast, ELFv1 Valgrind has worked just fine.

There are more issues with ELFv2 on powerpc64. Most prebuilt binaries target ELFv1, so i.e. bootstrapping Rust, GHC etc gets more annoying, and would require cross-compilation between ABIs or something weird like that. I know Adelie has their own prebuilt, prepatched Rust toolchain artefacts on their GitLab instance that they use for Rust things. I imagine that those might not just magically work for us though. With GHC, I'm even less sure about the state of ELFv2 support. All of these issues naturally go away when we don't force ELFv2.

So in short, yes it's legacy, but it Just Works ™️, and is the path of least resistance on this platform.

[flokli]

Forgot to hit comment, successfully built pkgsCross.ppc64-elfv{1,2}.kexec-tools. Thanks!