Well, I just got to stage2 in the build with llvm-as and, sure enough, it doesn't work:

llvm-as: Unknown command line argument '-iquotelibraries/ghc-prim/GHC'.  Try: '/nix/store/8cn6305g0gsrczz3ga298k0zilfzgs7r-llvm-20.1.8/bin/llvm-as --help'
llvm-as: Did you mean '--help-list-hidden'?
[...]

Anyway, back on clang, I'm getting many errors in the assembly that GHC generates, e.g.

/build/ghc44067_0/ghc_7.s:11:7: error:
     error: unknown operand
            subq    $40, %rsp
                    ^
   |
11 |         subq    $40, %rsp
   |       ^

I can upload a full log, but I doubt it's very insightful.

It seems that instead of targeting LLVM assembly, it's generating something else?

I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:

1. I set the target stage to 3 (instead of 1).
2. I removed the --host configure flag because the script still complains about "build != host"

I'm not very familiar with x86 assembly, but it does look like x86 assembly. Even though GHC is being explicitly given -fllvm.

I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:

1. I set the target stage to 3 (instead of 1 or 2).
2. I removed the --host configure flag because the script still complains about "build != host"

I'm not very familiar with x86 assembly, but it does look like x86 assembly. Even though GHC is being explicitly given -fllvm.

Is the TH external interpreter supposed to work?

iserv-proxy-interpreter: tmp/nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-linux-ghc-9.10.3/ghc-prim-0.12.0-561f/libHSghc-prim-0.12.0-561f.a: RTS linker not implemented on riscv
iserv-proxy-interpreter: loadArchive "tmp/nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-linux-ghc-9.10.3/ghc-prim-0.12.0-561f/libHSghc-prim-0.12.0-561f.a": failed

(Context: fixing the pkgsCross.riscv64.buildPackages.ghc build and trying to cross-compile some Haskell packages)

In reply to @sternenseemann:systemli.org
I guess you may need to amend the default for enableExternalInterpreter

Of course, then it is necessary to manually add the required paths to the package db after installation.

sterni would you happen to know how to do that, given that you mentioned it?
If not, I will spend some time figuring it out.
I tried your suggestion, and it is indeed in need of something extra for libffi to make the compiler fully functional.

ld.gold: error: cannot find -lffi

It looks like libffi is already in depsTargetTargetPropagated, so I don't understand why it's not made available in package builds.