| 19 Mar 2026 |
 sterni | Alex: https://gitlab.haskell.org/ghc/ghc/-/blob/f8817879f94e4ea3e603808fd6370b8365818911/configure.ac#L556 | 20:28:00 |
 Alex | 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'?
[...]
| 20:28:45 |
| sterni | ah it was lol https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13932 | 20:29:01 |
| Alex | 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? | 20:33:06 |
 teo (they/he) | https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15231 should make a big difference. Sven is currently splitting off bits from this large branch and getting them merged | 20:33:07 |
| sterni | Alex: do clang/LLVMAS version and LLVM version match? | 20:38:42 |
| Alex | I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:
- I set the target stage to 3 (instead of 1).
- 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. | 20:41:12 |
| Alex | * I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:
- I set the target stage to 3 (instead of 1 or 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. | 20:41:32 |
| Alex | 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) | 21:45:17 |
| sterni | cc alexfmpe | 21:51:23 |
| sterni | I guess you may need to amend the default for enableExternalInterpreter | 21:51:49 |
| Alex | Could maybe do something similar to common-have-ncg.nix, like common-have-rts-linker.nix.
Anyway, this feels like something that should be advertised by ghc.passthru and not blindly assumed (e.g. what if it's built without TH support?). | 21:58:58 |
| Alex | Anyway, here's the PR fixing pkgsCross.riscv64.buildPackages.ghc (but not touching the TH issue).
https://github.com/NixOS/nixpkgs/pull/501439 | 22:00:07 |
| Alex | * Here's the PR fixing pkgsCross.riscv64.buildPackages.ghc (but not touching the TH issue).
https://github.com/NixOS/nixpkgs/pull/501439 | 22:00:41 |
 alexfmpe | https://gitlab.haskell.org/ghc/ghc/-/commit/a0e417411fa6518436741aabe2c72e22a3309b19#b7ec52d5e302083ed03503182f1293694dda24f3_438_438 | 23:56:04 |
| alexfmpe | Seems to only have been supported for risc recently | 23:56:15 |
| alexfmpe | Maybe try 9.12 | 23:56:33 |
| alexfmpe | I never was able to test riscv because of the libffi error | 23:56:47 |
| 20 Mar 2026 |
| alexfmpe | In reply to @sternenseemann:systemli.org
I guess you may need to amend the default for enableExternalInterpreter Not sure there's a benefit. It would fail with the 'need external interpreter' message instead? | 00:19:48 |
| alexfmpe | As long as iserv-proxy builds for that platform, I don't think there's regressions by enabling external interpreter | 00:20:21 |
| Alex |
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. | 00:23:17 |
| Alex | That's true, but it does needlessly increase the build closure. | 00:24:18 |
| alexfmpe | Fair. There's an opt out for ghcjs, maybe add it for riscv, possibly conditional on version. Does 9.12 or 9.14 work? | 00:25:27 |
| alexfmpe | Also, treatment of libffi changed recently on ghc. Maybe try ghcHEAD | 00:26:34 |
| Alex | I noticed that GHC considers it important enough to mention whether the RTS linker exists in --info, so I'm leaning more and more in favour of adding it to passthru. | 00:33:50 |
 woobilicious | I'm thinking about writing a vulkan overlay to do smart frame rate limiting, convince me to do it in Haskell instead of rust... | 01:18:22 |
| woobilicious | I want to do it in Haskell, but that feels completely irrational, the GC is going to be more of a pain than a benefit, and I don't think I need any advanced typing features. | 01:21:54 |
 Jack (he/him) | I think it’ll depend a lot more on the quality of the Vulkan bindings than the GC. | 02:40:48 |
| Jack (he/him) | There’s a variety of GC knobs you can turn, including turning it off for a hot path, which is what high frequency trading shops do with GC languages. | 02:42:17 |
| woobilicious | Well that's what I mean by pain, not something to worry about in Rust. But you also have a point about bindings. | 03:05:20 |
