Haskell in Nixpkgs/NixOS - Public Room Timeline

	Haskell in Nixpkgs/NixOS	721 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
20 Mar 2026
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
Alex	I have it in both `library-dirs` and `include-dirs` for `rts-*.conf` yet GHC seems to not even try to link `libffi`. I'm looking at the output with vendored `libffi` and I can't see where it's getting linked, so there's no way to take inspiration from there. I could try adding `-lffi` to the `ld-options`. Is this approach sane?	22:41:52
alexfmpe	keep in mind next ghc release will handle libffi differently	23:19:42
alexfmpe	https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14996	23:19:44
Alex	Adding `-lffi` did not work. Somehow none of the `library-dirs` in `rts-*.conf` seem to be used; Haskell package builds fail with "error: cannot find -lffi". It's no surprise that they're changing the libffi handling soon, this is difficult to hack around.	23:59:52
21 Mar 2026
alexfmpe	I did PR a bump to ghcHEAD precisely to see if it affected the cross libffi shenanigans	00:24:50
alexfmpe	but iserv-proxy doesn't build with it yet	00:25:07
alexfmpe	maybe we just merge your PR as is and revisit when we can test cross on 10.0?	00:35:21
alexfmpe	* maybe we just merge your PR as is and revisit when we can test cross properly on 10.0?	00:35:37
alexfmpe	I also have no idea how the on-demand interpreter will shake things	00:35:47
woobilicious	Lol I got almost no where so far, converting a monomorphic C interface to a typesafe hetrogenous list type is way too complex for my puny brain.	05:07:12
sterni	teo (they/he): do you know whether there is already a GHC issues w.r.t. handling of system gmp/libffi in a cross context? I think a fundamental problem in GHC is that it assumes that the same (system) libffi and gmp flags can be passed during every stage, but when e.g. building a cross compiler, stage0 would need to use a different version of those libraries which has been built for the build platform.	13:59:16
sterni	I assume that the in tree gmp/libffi handle this just fine since it's recompiled for every stage (?)	13:59:54
sterni	One option I see would be to build stage0 without libffi and gmp altogether if that's possible	14:00:54
sterni	In any case, context is that I'm currently patching the system libffi handling slightly to special-case stage0 and I want to at least reference some issue, so would be good to have something related already, but can also open a new one.	14:02:28
sterni	Not sure if the patch would be upstreamable though I suspect that --with-system-* does not work when building a cross compiler with anything but Nix and with Nix it's sometimes broken if the headers are platform specific (i.e. libffi).	14:03:17
sterni	* Not sure if the patch would be upstreamable though I suspect that, currently, --with-system-* does not work when building a cross compiler with anything but Nix and with Nix it's sometimes broken if the headers are platform specific (i.e. libffi). So maybe it would be a net positive.	14:03:39

Show newer messages

Back to Room ListRoom Version: 6