| 30 Mar 2026 |
 JamieMagee | I found an issue with nixpkgs configuration of gdb, which doesn't match upstream configuration. Specifically, gdb doesn't support in-process agent on risc-v: https://github.com/NixOS/nixpkgs/pull/504872 | 03:41:58 |
 misuzu | Try --cores 1 | 07:14:37 |
 Alex | 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). 🫠| 10:16:04 |
| Alex | I have figured out a way to get LLVM linked with mold to evaluate (I think?) so I think I'll try that first. | 10:17:01 |
| misuzu | https://riseproject.dev/2026/03/24/announcing-the-rise-risc-v-runners-free-native-risc-v-ci-on-github/ | 16:21:14 |
 Tristan Ross | When I was doing stuff with the VF2, I had to compile LLVM on 1 core. That took like 3 days to build. | 16:42:12 |
 Alister Galpin | 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/ This sounds awesome! Hate that it's GitHub but maybe an initial build+cache could work I remember hearing someone was setting up a cache? | 18:16:55 |
| 31 Mar 2026 |
| Alex |
ld.mold: line 292: 8914 Killed
Not even mold can handle it (--cores 4). Time to suffer the 6-day long --cores 1 build. | 14:05:39 |
| 1 Apr 2026 |
|  Timofey Frolov joined the room. | 13:09:41 |
| 7 Apr 2026 |
| Alex | System rebuild is finally done.
My u-boot env was so scuffed that the new version didn't boot.
I flashed the latest version of u-boot, reset the env, and now it boots.
[root@nixos:~]# uname -a
Linux nixos 6.19.8 #1-NixOS SMP PREEMPT Fri Mar 13 16:26:05 UTC 2026 riscv64 GNU/Linux
[root@nixos:~]# nixos-version
26.05.20260316.b0515cb (Yarara)
| 20:04:19 |
| 8 Apr 2026 |
| JamieMagee set a profile picture. | 03:43:00 |
| 9 Apr 2026 |
 GenericNerdyUsername | Alyssa Ross i think i asked you about this a while ago, but is there some way to make a `riscv64-unknown-elf` toolchain? | 14:43:10 |
| GenericNerdyUsername | riscv64-none-elf might be functionally the same, but the thing i want to use wants specifically unknown-elf, and i dont if setup-hook fuckery means i can just make a bunch of symlinks | 14:44:14 |
| GenericNerdyUsername | * Alyssa Ross i think i asked you about this a while ago, but is there some way to make a riscv64-unknown-elf gcc toolchain? | 14:45:38 |
| Alex | I've seen before x86_64-unknown-linux vs x86_64-pc-linux in Nixpkgs, though I don't know whether that has led to any tooling of the kind you seek. | 14:49:03 |
 dramforever | i know this isn't your fault but please for the love of fuck stop hard coding prefixes
https://github.com/NixOS/nixpkgs/issues/145726#issuecomment-2799568568
https://github.com/rust-lang/pkg-config-rs/issues/53#issuecomment-3027915376 | 15:04:28 |
| dramforever | * i know this isn't your fault but please everyone for the love of fuck stop hard coding prefixes
https://github.com/NixOS/nixpkgs/issues/145726#issuecomment-2799568568
https://github.com/rust-lang/pkg-config-rs/issues/53#issuecomment-3027915376 | 15:04:52 |
| dramforever | just let me pass CROSS_COMPILE=riscv64-unknown-linux-gnu- or whatever it is | 15:05:04 |
| dramforever | * at least just let me pass CROSS_COMPILE=riscv64-unknown-linux-gnu- or whatever it is | 15:05:09 |
| dramforever | oh i knew i did this https://mastodon.social/@dramforever/114787497271979789 | 15:06:42 |
| dramforever | having said that, i wonder if you can "just" add unknown as a kernel type | 15:10:53 |
| dramforever | apparently yes, you can just patch nixpkgs like this https://fars.ee/gAvi and use (import <nixpkgs> { crossSystem.config = "riscv64-unknown-elf"; }).stdenvNoLibc.cc | 15:15:13 |
| dramforever | stdenv.cc doesn't work because we "obviously" don't have a libc for the "unknown" operating system | 15:16:23 |
| Alex | I wouldn't expect it to work for none OS either, though? | 15:17:09 |
| dramforever | so... | 15:24:42 |
| dramforever | on the none os we use newlib | 15:24:46 |
| Alex | That doesn't sound ideal to me, unless there's perhaps a way of building a custom stdenv without newlib even entiring the build closure (maybe via replaceStdenv?) | 15:26:41 |
| Alex | Anyway, that is purely theoretical, since nobody right now is asking about bare metal dev. | 15:27:14 |
| dramforever | riscv64-unknown-elf is without a doubt baremetal dev | 15:28:17 |
| Alex | Arguably, the behaviour Nixpkgs does on none should perhaps instead be for OS newlib, but maybe there's already precedent for this in other package repositories? | 15:31:19 |
