In reply to @alex:tunstall.xyz

I've measured ~22h for building an unregisterised GHC 9.2.8 booted via an unregisterised GHC 8.10.7 when running on VF2 (JH7110 SoC).
(Default flavour with profiled libraries, dynamic libraries, and documentation enabled.)

One minor difference to a typical RV64GC build is that I also enable Zba and Zbb.
I have no idea what performance impact this has on my hardware.

That a Milk-V Pioneer would take over 30h to do the same is surprising.

In reply to @alex:tunstall.xyz

I'm getting the following error when trying to build certain Haskell packages with a registerised GHC.

Couldn't find a target code interpreter. Try with -fexternal-interpreter

I thought registerised GHC included TemplateHaskell support?
Steven Keuchel do I need the patches that enable GHCi for this to work?

here is the part of my overlay that does this

      ghc964 =
        let
          override1 = super.haskell.compiler.ghc964.override {
            bootPkgs = self.haskell.packages.ghc963Binary;
          };
          override2 = override1.override {
            hadrian = override1.passthru.hadrian.overrideAttrs (oldAttrs: {
              patches = (oldAttrs.patches or [ ]) ++ [
                ./patches/hadrian-9.6.4-allow-Cabal-3.10.patch
                # https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10714
                (super.fetchpatch {
                  url = "https://gitlab.haskell.org/ghc/ghc/-/commit/dd38aca95ac25adc9888083669b32ff551151259.patch";
                  hash = "sha256-xqs6mw/akxMy+XmVabACzsIviIKP4fS0UEgTk0HJcIc=";
                  stripLen = 1;
                })
              ];
            });
          };
        in
        override2.overrideAttrs (oldAttrs: {
          patches = (oldAttrs.patches or [ ]) ++ [
            # https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12286
            (super.fetchpatch {
              url = "https://gitlab.haskell.org/ghc/ghc/-/commit/c5e47441ab2ee2568b5a913ce75809644ba83271.patch";
              hash = "sha256-t3KkuME6IqLWuESIMZ7OVAFu7s8G+x0ev+aVzBUqkhg=";
            })
          ];
        });

i'm surprised you haven't dealt with zeromq, because nix why-depends says systemd depends on it :

» nix why-depends --derivation nixpkgs#systemd nixpkgs#zeromq
/nix/store/mmxfq68bslpjqki0f7svg31cjv2pnr36-systemd-255.2.drv
└───/nix/store/js89ydnz71fv1kqgn69mm7yqfsw61lpi-iptables-1.8.10.drv
    └───/nix/store/5b85c19psp7km2mvnlwzs0gml93v289x-libpcap-1.10.4.drv
        └───/nix/store/rpgg2wwh745g9y928wb6a2w1gn23g9y1-libnl-3.8.0.drv
            └───/nix/store/hks3p38b5vdjkncdkkrcwjjqlhg1cbs7-graphviz-10.0.1.drv
                └───/nix/store/s5pcbnaqw75bxbyk3hyb2kmjr0b1viab-fontconfig-2.15.0.drv
                    └───/nix/store/q124gz30q037qq5n6vnym3n2gkf6r4n9-dejavu-fonts-minimal-2.37.drv
                        └───/nix/store/rngadqxkfwizz368b9zg3az9ifdgfgsn-dejavu-fonts-full-2.37.drv
                            └───/nix/store/rhw4k7zqgrvw36rz6cq5m6p12afpwc7l-fontforge-20230101.drv
                                └───/nix/store/ir6k22cspdsw25l4jskfrlmymhyr30g5-zeromq-4.3.5.drv

Why? Is there something wrong with zeromq on RISC-V?

I don't seem to have a fix for it and my full system rebuild is complete, so it should work fine.