Generally two options:

1. Latest and pray
2. Find someone else's (hopefully working) configuration and use the same revision as them

In reply to @alex:tunstall.xyz
Or is the issue unrelated to QEMU in that some things behave weirdly when userspace and kernelspace are on different architectures?

colemickens good news:

alex@alex-pc3 ~/r/O/n/ghc-cross-2 (ghc-cross-hadrian)> /nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/bin/riscv64-unknown-linux-gnu-ghc --info | grep platform
 ,("target platform string","riscv64-unknown-linux")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","riscv64-unknown-linux")

I'm still double checking that the cross-compiler works, but I expect to PR the fix to Nixpkgs soon enough.

This alone is not enough to cross-compile cachix:

---> Starting interpreter on port 6072
Listening on port 6072
iserv-proxy-interpreter: tmp/nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-linux-ghc-9.10.3/ghc-prim-0.12.0-561f/libHSghc-prim-0.12.0-561f.a: RTS linker not implemented on riscv
iserv-proxy-interpreter: loadArchive "tmp/nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-linux-ghc-9.10.3/ghc-prim-0.12.0-561f/libHSghc-prim-0.12.0-561f.a": failed

iserv-proxy: <socket: 17>: hGetBufSome: resource vanished (Connection reset by peer)
HasCallStack backtrace:
  collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:169:13 in ghc-internal:GHC.Internal.Exception
  toExceptionWithBacktrace, called at libraries/ghc-internal/src/GHC/Internal/IO.hs:260:11 in ghc-internal:GHC.Internal.IO
  throwIO, called at libraries/ghc-internal/src/GHC/Internal/IO/Exception.hs:315:19 in ghc-internal:GHC.Internal.IO.Exception
  ioException, called at libraries/ghc-internal/src/GHC/Internal/IO/Exception.hs:319:20 in ghc-internal:GHC.Internal.IO.Exception


/nix/store/vw5aaxwm2fppx1xarn7k41db5yr3rvww-iserv-wrapper-both/bin/iserv-wrapper: line 1: kill: (499) - No such process
<no location info>: error: External interpreter terminated (1)

I've been stuck for a few days on a problem with linking clangd-fuzzer getting OoM killed right at the end of buildPhase 18 hours into the clang build. Even -j1 isn't enough.
I tried useMoldLinker, but that's broken right now (due to something not putting NIX_CFLAGS_LINK under env?).
Then I tried updating the system again, but now useMoldLinker causes eval to overflow the stack.

Has anyone found a reasonable solution to building clang (LLVM 20 and 21) without needing ludicrous amounts of memory?
If push comes to shove I could perhaps suffer a larger swap file...

For reference:

[nixos@nixos:~/system]$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.0Gi       105Mi          0B       1.6Gi       1.5Gi
Swap:           15Gi       152Mi        15Gi

(There is high memory usage right now because it's in the middle of retrying clang.)

I had a build almost ending already, and this is what the RSS looked like just within 10s of the OoM kill:

436704 bin/c-index-test
4203668 bin/clang-tidy
2798596 bin/clangd-fuzzer

So yeah I think --cores 1 is worth a try, though it'll probably take over 2 days to build a single clang version (and I need 2). 🫠

In reply to @misuzu:matrix.org
https://riseproject.dev/2026/03/24/announcing-the-rise-risc-v-runners-free-native-risc-v-ci-on-github/

ld.mold: line 292: 8914 Killed

Not even mold can handle it (--cores 4). Time to suffer the 6-day long --cores 1 build.