Haskell in Nixpkgs/NixOS - Public Room Timeline

	Haskell in Nixpkgs/NixOS	724 Members
	For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs \| Current Docs: https://haskell4nix.readthedocs.io/	145 Servers

Load older messages

Sender	Message	Time
19 Mar 2026
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
Alex	It is also possible (but difficult) to write allocation-free code. The GC cannot trigger when the code doesn't allocate. I have no idea how you would regression test this approach.	04:25:06
woobilicious	Hmm, this seems non-trivial to resolve `error: /nix/store/8nvri8brvdbng3pkcrycik9b8na9jsyb-ghc-9.10.3-with-packages/lib/ghc-9.10.3/lib/../lib/x86_64-linux-ghc-9.10.3/rts-1.0.2/libHSrts-1.0.2.a(AutoApply.o): requires unsupported dynamic reloc 11; recompile with -fPIC`	07:14:25
woobilicious	okay so removing `options: standalone` fixed it but that might be undesirable for packaging, I guess no biggie for now	07:19:06
alexfmpe	`$ nix-build -A pkgsCross.riscv64.haskell.packages.ghc912.th-orphans /nix/store/cd58fv3lh6jplfszy2kq0w3i0pv517gq-th-orphans-riscv64-unknown-linux-gnu-0.13.17`	08:14:31
alexfmpe	* On your PR `$ nix-build -A pkgsCross.riscv64.haskell.packages.ghc912.th-orphans /nix/store/cd58fv3lh6jplfszy2kq0w3i0pv517gq-th-orphans-riscv64-unknown-linux-gnu-0.13.17`	08:14:48
alexfmpe	non-TH also works for loongarch	09:01:21
alexfmpe	I've seen different libffi errors elsewhere, will try to reproduce tomorrow and check against this	09:02:09
sterni	In reply to @alex:tunstall.xyz 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. you sed it in after library-dirs and include-dirs I can find you an example later	09:45:53

Show newer messages

Back to Room ListRoom Version: 6