In reply to @sorear:matrix.org
cross-compiled nixos using a mix of instructions from yesteday. built ubootQemuRiscv64SMode and used that with qemu to boot it. got halfway into stage 1 before failing to mount the root device.

hacked extlinux.conf to add rdinit=/nix/store/.../bin/hush (do people care about the <100 bytes that adding a /bin/sh symlink to the initramfs would add?) allowed me to debug that, discovered that the pci_host_generic module was missing.

added to boot.initrd.availableKernelModules. failed to log in.

added a users block. success!

In reply to @hive:the-apothecary.club
ok so as far as i understand it, ghc doesn't support cross-compilation, ( pending PR merge ), so you need to do an emulated build, but also as far as i can tell, flakes doesn't support doing an emulated build ?

Flakes support binfmt emulation.

The issue is that Nixpkgs doesn't know how to bootstrap GHC on RISC-V, because it doesn't know where to get a binary for GHC.

Your options are either:

1. Find a pre-compiled RISC-V binary for GHC somewhere (e.g. Debian might have one).
2. Use the unmerged PR to cross-compile a suitable bootstrap binary for GHC.

In reply to @hive:the-apothecary.club
so even with an emulated build, it still doesn't bootstrap successfully ?

Nixpkgs doesn't even evaluate, because it doesn't know where to find the RISC-V bootstrap binary.

See for yourself:

nix-shell -p '(import <nixpkgs> { system = "riscv64-linux"; }).ghc'

When building GHC from source, here's what Nixpkgs does:

1. It fetches an appropriate GHC bindist from haskell.org (none exists for RISC-V).
2. It uses the bindist to compile GHC.

(It is also possible to use the bindist directly, but AFAIK users rarely do that.)

In reply to @alex:tunstall.xyz

Flakes support binfmt emulation.

The issue is that Nixpkgs doesn't know how to bootstrap GHC on RISC-V, because it doesn't know where to get a binary for GHC.

In reply to @alex:tunstall.xyz

When building GHC from source, here's what Nixpkgs does:

1. It fetches an appropriate GHC bindist from haskell.org (none exists for RISC-V).
2. It uses the bindist to compile GHC.

(It is also possible to use the bindist directly, but AFAIK users rarely do that.)

In reply to @skeuchel:matrix.org
I tried using a self-compiled ghc963 bindist for rv64 directly to avoid recompiling ghc every now and then. Unfortunately a couple of packages fail to compile this way. also happens on amd64, try e.g. nixpkgs#haskell.packages.ghc963Binary.generics-sop.

The bindists only need to work well enough to compile GHC, so I assume that in Nixpkgs they might not be tested well enough for everything to work like it does with the Nixpkgs-native builds.

This is still quite puzzling though, as those bindists generally work well in FHS-compatible distributions.

In reply to @skeuchel:matrix.org
I tried using a self-compiled ghc963 bindist for rv64 directly to avoid recompiling ghc every now and then. Unfortunately a couple of packages fail to compile this way. also happens on amd64, try e.g. nixpkgs#haskell.packages.ghc963Binary.generics-sop.

I tried building generics-sop with various compilers.

x86_64, ghc963Binary = fails
x86_64, ghc963 = ok
x86_64, ghc928 = ok
RV64GC, ghc928 (cross-compiled from x86_64) = fails on th-abstraction (relocation R_RISCV_HI20 against a local symbol' can not be used when making a shared object; recompile with -fPIC) RV64GC, ghc928` (native, booted with cross-compiled 8.10.7) = ok

All compilers except ghc963Binary were built using Nixpkgs (cross-compiled versions required a custom branch).

(Excuse the old RV64GC compiler versions. My dev board hasn't been updated in months and I don't have the patience to wait 15+ hours for a new GHC version to compile.)