Code change:
<ins> { lib , stdenv }: # Trick to build a gcc that is capable of emitting shared libraries *without* having the # targetPlatform libc available beforehand.  Taken from: #   https://web.archive.org/web/20170222224855/http://frank.harvard.edu/~coldwell/toolchain/ #   https://web.archive.org/web/20170224235700/http://frank.harvard.edu/~coldwell/toolchain/t-linux.diff let # crt{i,n}.o are the first and last (respectively) object file # linked when producing an executable.  Traditionally these # files are delivered as part of the C library, but on GNU # systems they are in fact built by GCC.  Since libgcc needs to # build before glibc, we can't wait for them to be copied by # glibc.  At this early pre-glibc stage these files sometimes # have different names. crtstuff-ofiles = if stdenv.targetPlatform.isPower then "ecrti.o ecrtn.o ncrti.o ncrtn.o" else "crti.o crtn.o"; # Normally, `SHLIB_LC` is set to `-lc`, which means that # `libgcc_s.so` cannot be built until `libc.so` is available. # The assignment below clobbers this variable, removing the # `-lc`. # # On PowerPC we add `-mnewlib`, which means "libc has not been # built yet".  This causes libgcc's Makefile to use the # gcc-built `{e,n}crt{n,i}.o` instead of failing to find the # versions which have been repackaged in libc as `crt{n,i}.o` # SHLIB_LC = lib.optionalString stdenv.targetPlatform.isPower "-mnewlib"; in '' echo 'libgcc.a: ${crtstuff-ofiles}' >> libgcc/Makefile.in echo 'SHLIB_LC=${SHLIB_LC}' >> libgcc/Makefile.in '' </ins>

Related discussion:
text: On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically.