Change:
# indeed GHC will refuse to compile with a binutils suffering from it. See # this comment for more information: # https://gitlab.haskell.org/ghc/ghc/issues/4210#note_78333 <del> lib.optional stdenv.targetPlatform.isAarch32 ./R_ARM_COPY.patch; </del> <ins> lib.optional (stdenv.targetPlatform.isAarch32 && stdenv.hostPlatform.system != stdenv.targetPlatform.system) ./R_ARM_COPY.patch; </ins> outputs = [ "out" "info" "man" ];

Discussion:
Describe the bug (and, therefore, pretty much any package) fails to build on armv6l. To Reproduce Steps to reproduce the behavior: an armv6l machine. (I actually used an aarch64 Raspberry Pi 4B.) Additional context The segfault comes from , which is invoked by the Linux kernel build system. Here's a minimal C program that segfaults, when compiled with the from : A git bisect reveals that the faulty commit is (). Notify maintainers maintainer of binutils (since that's what seems to be the culprit here) author of Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(gaelan): channels(root): nixpkgs: Maintainer information:
I guess that this patch should only be enabled on armv7l then. Truthfully that PR was just changes proposed/written by others and someone else is probably more qualified wrt binutils to say what the correct thing to do would be.
I don't think it's an armv6l vs. armv7l thing: fails in the same way. There's a possibility that the issue is that I'm trying to build on a Pi 4, which is actually a 64-bit machine, with a 64-bit kernel. To test this, I copied the linux-headers closure, and all of its deps, to a Pi 0 W (which is actually armv6l), and got the same bug. It is still possible that the issue arises due to the Pi 4 miscompiling one of the dependences. I'm doing a full build on the Pi 0 to rule this out, but of course that could take a while.
Alright, also fails when building from scratch on a Pi 0. At this point, I'm pretty sure this patch just breaks building anything natively on aarch32.
Thanks for the testing I'm not sure what's more important, cross compiling to arm32 or native compiling! Hopefully can shed some light here.
What a mess! I guess the patch fixes some relocations breaks others. If we could make minimal programs for both that would be nice, but that's a lot of work.
Ah I see already minimized in , and we can cross-reference Jessica's patch on this issue too.

So maybe once we minimize this issue we'll have enough combinations to try that it shouldn't be so bad.
I have this problem on armv7l as well, on the novena board. 5.9.8 headers required for building nix fail.
I'm running into the exact same issue using arm emulation via on my x64 machine.
IIRC GHC was the only package affected by the bug in my NixOS closure when I had it running on an armv7 machine back in 2019 and it was also happening on native builds; had nothing to do with musl or cross. Couldn't we just make a special binutils with the patch for GHC and the (at worst) handful of other programs which need it?
Hello everyone, I'm trying to make use of the recent changes. Here what I've done: I'm using the nix installer from . I guess this should actually not be needed any more as we now have for this merged . Using my Pi4 with 32bit kernel: pi $ uname -a Linux raspberrypi 5.10.17-v7l+ SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux on the unstable channel (should not be relevant) and on current running: now passes. W-h-o-o . However, compiling our friendly greeting: results in the following segfault: Seems like this PR has not been all to fix the broken target. Anyone aware of the issue here and how to continue? Happy to update the official Wiki as soon as I've things working ... also including the hydra tarball. Thanks!
try cherry-picking commit from
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Thanks . That definitely helped but failing at stage4 now: Hmm, looks like the OS killed it? - maybe OOM? I guess there is a way to reduce memory load by reducing the number of parallel jobs? Do we know the minimal config right now?
I had no issues building the entire system (with a few tweaks) on armv7l virtual machine with 4 cores and 4G of RAM. You can try building with . Do you use NixOS? If not, is nix installed in multi-user mode?

Yes, OOM often produces exactly this "killed" log line.
Also make sure you have zram swap (perhaps even with zstd) if you're running into OOM issues. It's free additional RAM space.
Hitting the exact same bug when cross-compiling to armv7l now, in packages that have PIC disabled (zfs)