Code change:
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. Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.

Related discussion:
text: liberation_ttf_v1_from_source = throw "'liberation_ttf_v1_from_source' has been renamed to/replaced by 'liberation_ttf_v1'"; # Converted to throw 2022-02-22 liberation_ttf_v2_from_source = throw "'liberation_ttf_v2_from_source' has been renamed to/replaced by 'liberation_ttf_v2'"; # Converted to throw 2022-02-22 liberationsansnarrow = throw "'liberationsansnarrow' has been renamed to/replaced by 'liberation-sans-narrow'"; # Converted to throw 2022-02-22 <del> libgcc = throw "libgcc was removed, use gcc.cc.libgcc if needed"; # added 2023-05-13 </del> libgksu = throw "libgksu has been removed"; # Added 2022-01-16 libgme = game-music-emu; # Added 2022-07-20 libgnome_keyring = throw "'libgnome_keyring' has been renamed to/replaced by 'libgnome-keyring'"; # Converted to throw 2022-02-22