| 3 Apr 2024 |
 [0x4A6F] | Thanks Alex for that writeup and your work on cross bootstraping GHC. ❤️ | 16:17:31 |
 Alex | In reply to @0x4a6f:matrix.org
And it wasn't saved because of that calc-captcha... -> https://wiki.nixos.org/wiki/RISC-V/GHC Pain. I was going to copy it over to the wiki anyway. I guess I might touch it up a bit to make it more flake-friendly. | 16:43:31 |
| Alex | In reply to @0x4a6f:matrix.org
Thanks Alex for that writeup and your work on cross bootstraping GHC. ❤️ I still need to figure out what's causing the registerised segfaults, so it's not done yet. | 16:44:39 |
| Alex | The rustc build is segfaulting on native builds too 🙃
Seems to be https://github.com/rust-lang/rust/issues/117022
Now beginning to wonder if all the GHC segfaults aren't also kernel-related... | 18:02:35 |
| Alex |
- rustc segfaults due to the 6.5 kernel(?).
- uboot-tools is needed to build the 6.8 kernel.
- python3-cryptography is needed to build uboot-tools.
- rustc is needed to build python3-cryptography.
I'm glad I've never GCed on this system, because I might need to run an older kernel to upgrade the kernel... | 19:50:19 |
 Li-ion | https://github.com/NixOS/nixpkgs/issues/301340 | 20:01:35 |
| Li-ion | do you think all of the segfault errors on my builds are related to this kernel as well ? | 20:02:02 |
| Alex | In reply to @hive:the-apothecary.club
do you think all of the segfault errors on my builds are related to this kernel as well ? I doubt it, because QEMU uses the host system's kernel. | 20:02:25 |
| Li-ion | ah ok | 20:02:35 |
| Alex | I guess you could try using a different version if you're on 6.5 though?
It just might work. I don't really understand the root cause of my segfaults well enough to say. | 20:03:23 |
| Li-ion | i'm on 6.8 | 20:03:44 |
| 4 Apr 2024 |
|  Guilhem joined the room. | 09:22:20 |
 hexa | anyway, debian is building on hifive unmatched 😄 | 09:23:54 |
| hexa | my employer seems to host a bunch of these 👀 | 09:24:45 |
 fgaz | hexa: as far as I know our main limitation is rack space (ping Mic92). the upcoming milk-v oasis seems like a more efficient use of that space | 09:31:27 |
| hexa | huh? rack space where? | 09:31:43 |
| hexa | TUM? | 09:32:01 |
 Pratham Patel (you can mention me) | In reply to @fgaz:matrix.org
hexa: as far as I know our main limitation is rack space (ping Mic92). the upcoming milk-v oasis seems like a more efficient use of that space The third RISC-V SoM from Sipeed is gonna have the same SG2380 SoC that the Oasis will too. Not sure on the max memory that they will ship. So for CPU-bound compiles, this SoM should be better if $ and space are an issue.
https://twitter.com/sipeedio/status/1774644666375524659
| 09:34:19 |
| fgaz | In reply to @hexa:lossy.network
huh? rack space where? In the nix community rack. Last time we discussed this I think that was the candidate for hosting a builder. I don't know more than that | 09:35:32 |
 Julien | And the pioneer is a no go ? | 09:36:50 |
| Pratham Patel (you can mention me) | In reply to @julienmalka:matrix.org
And the pioneer is a no go ? Yes. | 09:37:02 |
| Pratham Patel (you can mention me) | All machines with the C910 core are only good for test builds and cannot be "trusted" (not in context of a backdoor but it is not compliant to the spec). | 09:38:00 |
| Pratham Patel (you can mention me) | The "v2" of C920 is supposed to be more compliant with the spec but no one has had hands-on with it yet. | 09:38:48 |
|  ShalokShalom joined the room. | 10:05:05 |
| ShalokShalom | Hi there. I heard about the attempts to bootstrap the GHC on NixOS RISC-V. I guess you tried the LLVM backend? Sorry if thats a bit naive, I guess there is a very good reason, why this wouldnt work. The Github ticket around this issue also mentions, that this is possible. Is the backend not capable to compile itself? | 10:31:29 |
| ShalokShalom | * Hi there. I heard about the attempts to bootstrap the GHC on NixOS RISC-V. I guess you tried the LLVM backend? Sorry if thats a bit naive, I guess there is a very good reason, why this wouldnt work. The Github ticket around this issue also mentions, that this is possible. Is the LLVM backend not capable to compile GHC? | 10:32:42 |
| ShalokShalom | I do see the GraalVM also as a potential tool to bootstrap Haskell on RISC-V, although I havent tried that yet. They provide both JIT and compiled (they call it native image) methods to run on RISC-V, and Haskell supposedly runs on it with the Sulong implementation.
Just wanted to drop it, in case someone didnt knew about that yet (sorry if obviously not helpful, as said.) | 10:37:16 |
 Steven Keuchel | You can always build GHC with an unregisterised backend (via C), and use that to bootstrap. But that is painfully slow. There is no NCG backend and not runtime linker yet, but that's in progress. The LLVM backend "works" as of 9.6 (or 9.4 with newer llvm like in debian). | 10:39:52 |
|  eyJhb joined the room. | 11:21:01 |
| Alex | In reply to @skeuchel:matrix.org
You can always build GHC with an unregisterised backend (via C), and use that to bootstrap. But that is painfully slow. There is no NCG backend and not runtime linker yet, but that's in progress. The LLVM backend "works" as of 9.6 (or 9.4 with newer llvm like in debian). In my testing using an unregisterised boot GHC, it usually takes around 20 hours to natively build GHC on the JH7110 SoC. Longer if other builds are running in parallel (I've had one GHC build take ~35 hours).
I can't comment on how much faster registerised via LLVM is because my registerised builds keep segfaulting... | 12:19:51 |
