https://community.milkv.io/t/introducing-the-milk-v-oasis-with-sg2380-a-revolutionary-risc-v-desktop-experience/780

H extension => NixOS tests!

In reply to @twz123:matrix.org
> to avoid bootstrapping

Does anybody have a RISC-V binary cache somewhere? I'm not even able to get cachix compiled. AFAICT GHC can't be bootstrapped on riscv64 and cross compiling doesn't work either (due to Template Haskell stuff not being able to be cross compiled). Only idea that I have currently is to copy the store paths over to other machines on which cachix is available.

GHC can be bootstrapped, but it's not yet in Nixpkgs haskell-updates.
https://github.com/NixOS/nixpkgs/pull/243619
(Note that there is also an unrelated bug with cross-compiling {cc,binutils}-wrapper that you'll want to fix before building. See first comment.)

As for existing binary caches, there are a few, e.g. https://github.com/misuzu/nixos-vf2/blob/master/flake.nix#L3
Even then, I doubt you'll find much beyond the absolutely necessary tools in these caches.

Be warned that TH is completely broken on RISC-V in general because GHC has to be built unregistered (see https://gitlab.haskell.org/ghc/ghc/-/issues/23957), and Nixpkgs doesn't have anything in place to make TH work in cross/unregisterised scenarios.

Most Haskell packages can still be built by disabling test suites (when they depend on TH) and overriding Cabal files (when the package uses a multithreaded-only RTS flag).

Be warned that TH is completely broken on RISC-V in general because GHC has to be built unregisterised (see https://gitlab.haskell.org/ghc/ghc/-/issues/23957), and Nixpkgs doesn't have anything in place to make TH work in cross/unregisterised scenarios.

Most Haskell packages can still be built by disabling test suites (when they depend on TH) and overriding Cabal files (when the package uses a multithreaded-only RTS flag).

In reply to @alex:tunstall.xyz

GHC can be bootstrapped, but it's not yet in Nixpkgs haskell-updates.
https://github.com/NixOS/nixpkgs/pull/243619
(Note that there is also an unrelated bug with cross-compiling {cc,binutils}-wrapper that you'll want to fix before building. See first comment.)

As for existing binary caches, there are a few, e.g. https://github.com/misuzu/nixos-vf2/blob/master/flake.nix#L3
Even then, I doubt you'll find much beyond the absolutely necessary tools in these caches.

In reply to @twz123:matrix.org
Thanks. You mean that when trying out the aforementioned PR, I might be able to get GHC compiled? Will try that out. I don't have any idea about Haskell whatsoever, so I'd probably not be able to override anything in the Cabal files. (I can override stuff with doCheck=false though and see if that gets me anywhere 😄). I'll check out cache.ztier.in. It'd already help if only stdenv would be in there. Bootstrapping gcc is no fun 😵‍💫. Do you know who maintains that cache?

You can get GHC compiled with that. There is some useful information in the PR about how to do it, but the idea is cross-compile from another architecture, copy to RISC-V machine, and use it to compile natively.
Unless you have a very unusually powerful RISC-V system, expect the native build to take over 20 hours (you may be able to make it faster by changing the GHC build flavour). At the moment, it doesn't give much advantage over the cross build, so you could just use that instead.

For overriding Haskell packages, there are some very useful functions in haskell.lib.
For dropping RTS flags, you can use those functions to remove any --with-rtsopts if you get any "unsupported RTS flag" issues (note that some programs might behave strangely with single-threaded RTS).

I'd be very surprised if the binary cache didn't have stdenv when using the same version of Nixpkgs.
I don't know who maintains it, but I'm guessing that whoever added it to the file is responsible (see git blame).

I don't know

You can get GHC compiled with that. There is some useful information in the PR about how to do it, but the idea is cross-compile from another architecture, copy to RISC-V machine, and use it to compile natively.
Unless you have a very unusually powerful RISC-V system, expect the native build of GHC to take over 20 hours (you may be able to make it faster by changing the GHC build flavour). At the moment, it doesn't give much advantage over the cross build, so you could just use that instead.

For overriding Haskell packages, there are some very useful functions in haskell.lib.
For dropping RTS flags, you can use those functions to remove any --with-rtsopts if you get any "unsupported RTS flag" issues (note that some programs might behave strangely with single-threaded RTS).

I'd be very surprised if the binary cache didn't have stdenv when using the same version of Nixpkgs.
I don't know who maintains it, but I'm guessing that whoever added it to the file is responsible (see git blame).

I don't know

You can get GHC compiled with that. There is some useful information in the PR about how to do it, but the idea is cross-compile from another architecture, copy to RISC-V machine, and use it to compile natively.
Unless you have a very unusually powerful RISC-V system, expect the native build of GHC to take over 20 hours (you may be able to make it faster by changing the GHC build flavour). At the moment, it doesn't give much advantage over the cross build, so you could just use that instead.

For overriding Haskell packages, there are some very useful functions in haskell.lib.
For dropping RTS flags, you can use those functions to remove any --with-rtsopts if you get any "unsupported RTS flag" issues (note that some programs might behave strangely with single-threaded RTS).

I'd be very surprised if the binary cache didn't have stdenv when using the same version of Nixpkgs.
I don't know who maintains it, but I'm guessing that whoever added it to the file is responsible (see git blame).

In reply to @twz123:matrix.org

to avoid bootstrapping

Does anybody have a RISC-V binary cache somewhere? I'm not even able to get cachix compiled. AFAICT GHC can't be bootstrapped on riscv64 and cross compiling doesn't work either (due to Template Haskell stuff not being able to be cross compiled). Only idea that I have currently is to copy the store paths over to other machines on which cachix is available.