| 18 Mar 2026 |
 dramforever | it "worked", but nobody got around to actually marking stuff... | 16:45:48 |
 Alyssa Ross | globally disable checking if using binfmt imo 😈️ | 16:49:41 |
| dramforever | i need to get nix --binfmt-misc pr'd into nix some time... | 16:50:49 |
| dramforever | if you haven't seen, https://github.com/dramforever/nix/pull/25 | 16:51:16 |
| dramforever | it's just a little bit too hacky, and the rabbit hole got so deep i sent a patch to linux man-pagea | 16:51:55 |
| dramforever | * it's just a little bit too hacky, and the rabbit hole got so deep i sent a patch to linux man-pages | 16:52:02 |
 JamieMagee | Yeah, qemu-user | 17:39:14 |
| 19 Mar 2026 |
| JamieMagee | I appreciate you taking the time to look into it with me. I've closed out my PR and I'll workaround it locally with an overlay. | 05:20:07 |
 Alex | Frankly, I'm surprised that QEMU continues to get RISC-V emulation subtly wrong. | 06:13:22 |
| Alex | Or is the issue unrelated to QEMU in that some things behave weirdly when userspace and kernelspace are on different architectures? | 06:15:15 |
| Alyssa Ross | often qemu-user just doesn't implement certain stuff — remember it's not just emulating the architecture; it has to emulate the whole Linux API | 06:23:38 |
| dramforever | -ENOSYS is one of the least subtle wrongs qemu-user commits | 12:39:17 |
| dramforever | but yes usually you can expect user emulation to have a crap ton more problems than system emulation | 12:40:03 |
 colemickens | Is there a branch y'all follow or maintain? Or just ride nixos-unstable and cross your fingers? :) | 19:17:42 |
| Alex | Generally two options:
- Latest and pray
- Find someone else's (hopefully working) configuration and use the same revision as them
| 19:22:52 |
 Sergei Zimmerman (xokdvium) | 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? Well, nix is one for example https://github.com/NixOS/nix/issues/15153 | 20:16:49 |
| Alex | Yes, I ran into that issue myself a few weeks ago while doing binfmt emulation of aarch64. | 20:18:01 |
| Sergei Zimmerman (xokdvium) | I guess it should be pretty easy to fix by just calling uname and using the appropriate arch for setting up seccomp? | 20:23:35 |
| Alex | 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. | 21:35:58 |
| Alex | 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)
| 21:43:39 |
| Alex | colemickens https://github.com/NixOS/nixpkgs/pull/501439 | 22:00:19 |
| 20 Mar 2026 |
|  @silvio:booq.org left the room. | 09:01:21 |
| 24 Mar 2026 |
|  @theo-paris:matrix.org left the room. | 04:05:49 |
| 28 Mar 2026 |
| colemickens | I'm sort of a riscv noob, especially with regards to the ... revisions? Is TH1520 too old to use to build in nixpkgs? | 22:54:04 |
| 29 Mar 2026 |
| Alex | That seems to be RV64GC (with an old(?) version of RVV?) so unless you're deliberately targeting a higher profile like RVA23, it should be OK. | 01:58:44 |
| dramforever | th1520 should be fine | 03:41:26 |
|  faukah left the room. | 18:11:58 |
| colemickens | I have no idea what I was doing last night. I rebooted my builders and went back to a newer nixos-unstable and now thing seem to be building mostly fine. Really bizarre, but I was up late, maybe I was more tired than I thought. | 18:44:16 |
| Alex | 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... | 18:51:51 |
| Alex | 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.) | 18:53:30 |
