!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

737 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/147 Servers

Load older messages

SenderMessageTime
16 Mar 2026
@eveeifyeve:matrix.orgeveeifyeve* I forgot to mention this, It's not just that pr is linked it's across globally, because I was happened to reproduce it. Ref: https://github.com/NixOS/nixpkgs/pull/499983#issuecomment-406291605822:40:32
@alexfmpe:matrix.orgalexfmpeheh you barely missed 500k22:44:25
18 Mar 2026
@alex:tunstall.xyzAlex

It seems that we have a regression in pkgsCross.riscv64.buildPackages.ghc:

error: In file included from /nix/store/77digc4i0ny4i31cwns7zpirak96np5r-libffi-riscv64-unknown-linux-gnu-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/77digc4i0ny4i31cwns7zpirak96np5r-libffi-riscv64-unknown-linux-gnu-3.5.2-dev/include/ffitarget.h:36:2: error: #error "libffi was configured for a RIS
C-V target but this does not appear to be a RISC-V compiler."
   36 | #error "libffi was configured for a RISC-V target but this does not appear to be a RISC-V compiler."
      |  ^~~~~

(On latest nixpkgs-unstable)

sterni Is this known about?
We might need to bisect for the cause.

pkgsCross.riscv64.haskell.compiler.ghc94 still builds, but cross-compiling other Haskell packages has been a bit of a blind spot for me.

02:27:59
@alex:tunstall.xyzAlex *

It seems that we have a regression in pkgsCross.riscv64.buildPackages.ghc:

error: In file included from /nix/store/77digc4i0ny4i31cwns7zpirak96np5r-libffi-riscv64-unknown-linux-gnu-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/77digc4i0ny4i31cwns7zpirak96np5r-libffi-riscv64-unknown-linux-gnu-3.5.2-dev/include/ffitarget.h:36:2: error: #error "libffi was configured for a RIS
C-V target but this does not appear to be a RISC-V compiler."
   36 | #error "libffi was configured for a RISC-V target but this does not appear to be a RISC-V compiler."
      |  ^~~~~

(On latest nixpkgs-unstable)

sterni Is this known about?
We might need to bisect for the cause, assuming this ever worked.

pkgsCross.riscv64.haskell.compiler.ghc94 still builds, but cross-compiling other Haskell packages has been a bit of a blind spot for me.

02:30:11
@alex:tunstall.xyzAlex Reproducer: https://gist.github.com/colemickens/78af9a28c01b888726322ca6628b27f5 02:30:29
@alex:tunstall.xyzAlex I went back to 22.05 and it still failed.
Did this ever work? 		04:00:56
@alexfmpe:matrix.orgalexfmpeno clue but I've also seen FFI define errors for a few months now when trying to build for other archs04:21:32
@alexfmpe:matrix.orgalexfmpe 
$ nix-build -A pkgsCross.loongarch64-linux.haskellPackages.ghc
error: In file included from /nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffitarget.h:38:2: error: #error "libffi was configured for a LoongArch target but this does not appear to be a LoongArch compiler."
04:21:41
@alexfmpe:matrix.orgalexfmpehttps://github.com/libffi/libffi/blob/master/src/loongarch64/ffitarget.h#L39 https://github.com/libffi/libffi/blob/master/src/riscv/ffitarget.h#L3604:23:15
@alexfmpe:matrix.orgalexfmpeI do not see these "was configured" errors coming from symbol checks in x86 or aarch64 https://github.com/libffi/libffi/blob/master/src/x86/ffitarget.h https://github.com/libffi/libffi/blob/master/src/aarch64/ffitarget.h04:24:25
@alexfmpe:matrix.orgalexfmpe* https://github.com/libffi/libffi/blob/master/src/loongarch64/ffitarget.h#L39 https://github.com/libffi/libffi/blob/master/src/mips/ffitarget.h#L57 https://github.com/libffi/libffi/blob/master/src/riscv/ffitarget.h#L3604:37:11
@alexfmpe:matrix.orgalexfmpe * 
$ nix-build -A pkgsCross.loongarch64-linux.haskellPackages.ghc
error: In file included from /nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffitarget.h:38:2: error: #error "libffi was configured for a LoongArch target but this does not appear to be a LoongArch compiler."

$ nix-build -A pkgsCross.mips64-linux-gnuabi64.haskellPackages.ghc 
error: In file included from /nix/store/8q1grm46k375rmfmbzvsxnhzbakksf6n-libffi-mips64-unknown-linux-gnuabi64-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/8q1grm46k375rmfmbzvsxnhzbakksf6n-libffi-mips64-unknown-linux-gnuabi64-3.5.2-dev/include/ffitarget.h:57:3: error: #error -- something is very wrong --
   57 | # error -- something is very wrong --
      |   ^~~~~
04:38:46
@alexfmpe:matrix.orgalexfmpe * 
$ nix-build -A pkgsCross.loongarch64-linux.haskellPackages.ghc
error: In file included from /nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffitarget.h:38:2: error: #error "libffi was configured for a LoongArch target but this does not appear to be a LoongArch compiler."
   38 | #error \
      |  ^~~~~
/nix/store/kn3j1mjbcj7w39h0s0wgxxhchw3gg56f-libffi-loongarch64-unknown-linux-gnu-3.5.2-dev/include/ffitarget.h:66:2: error: #error unsupported LoongArch base architecture
   66 | #error unsupported LoongArch base architecture
      |  ^~~~~

$ nix-build -A pkgsCross.mips64-linux-gnuabi64.haskellPackages.ghc 
error: In file included from /nix/store/8q1grm46k375rmfmbzvsxnhzbakksf6n-libffi-mips64-unknown-linux-gnuabi64-3.5.2-dev/include/ffi.h:84,
                 from FFI.hsc:33:
/nix/store/8q1grm46k375rmfmbzvsxnhzbakksf6n-libffi-mips64-unknown-linux-gnuabi64-3.5.2-dev/include/ffitarget.h:57:3: error: #error -- something is very wrong --
   57 | # error -- something is very wrong --
      |   ^~~~~
04:41:10
@woobilicious:matrix.orgwoobiliciousI have a questions about the general architecture of haskellPackages, does hackage have dep cycles? and how do you deal with them when generating the package list? I'm working on a little project that generates a package list from a foreign source, but it has cycles, and I'm kinda clueless on how to break cycles up without just removing all dependencies04:49:25
@alex:tunstall.xyzAlex Cross-compiling GHC 9.6+ shouldn't even eval, because of a throw sterni added after we found that Hadrian broke cross. Is there some difference between haskellPackages.ghc and haskell.compiler.ghc? 05:40:55
@alex:tunstall.xyzAlex

I have not seen anything that suggests that Cabal supports cycles, but you may want to try it out and see whether the dependency solver likes it.

But regardless of what Haskell is doing, I think you would be better off looking at how existing tools that work with the foreign source handle those cycles, since doing the same thing will give your tooling the best chance at doing no worse with weird scenarios you've yet to consider.

05:46:36
@alexfmpe:matrix.orgalexfmpeNot for native 05:46:36
@alexfmpe:matrix.orgalexfmpe
In reply to @alexfmpe:matrix.org
Not for native
One is cross compiler ghc, the other is cross compiled ghc 		05:47:31
@alex:tunstall.xyzAlex Right, so haskellPackages.ghc is the same as buildPackages.ghc? 05:48:13
@alexfmpe:matrix.orgalexfmpe
In reply to @woobilicious:matrix.org
I have a questions about the general architecture of haskellPackages, does hackage have dep cycles? and how do you deal with them when generating the package list? I'm working on a little project that generates a package list from a foreign source, but it has cycles, and I'm kinda clueless on how to break cycles up without just removing all dependencies
You can have package cycles, just not component cycles. For packages A,B it's valid to have libA <- libB <- testA 		05:50:04
@alexfmpe:matrix.orgalexfmpeIn cabal packages that is05:50:24
@alexfmpe:matrix.orgalexfmpehaskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component05:50:54
@alexfmpe:matrix.orgalexfmpeSo we have to manually break cycles for a bunch of test packages with dontCheck05:51:15
@alexfmpe:matrix.orgalexfmpeSearch for 'cycle' or so in configuration-common.nix for examples05:51:40
@alexfmpe:matrix.orgalexfmpe`nix-build --show-trace` can help find specific cycles since it shows the call stack05:52:47
@alexfmpe:matrix.orgalexfmpe
In reply to @alex:tunstall.xyz
Right, so haskellPackages.ghc is the same as buildPackages.ghc?
I think so, though it seems completely backwards to me 		05:53:21
@alexfmpe:matrix.orgalexfmpeI'd expect haskellPackages.foo to always have the same host platform05:53:46
@alexfmpe:matrix.orgalexfmpe* I'd expect pkgsCross.foo.haskellPackages.bar to always have 'foo' as same host platform for all 'bar'05:54:28
@alexfmpe:matrix.orgalexfmpeBut bar=ghc acts special05:54:53
@alexfmpe:matrix.orgalexfmpe
In reply to @alexfmpe:matrix.org
haskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component
Or rather, cabal2nix is wrong, and haskellPackages is based on throwing cabal2nix at hackage 		05:55:40

Show newer messages

Back to Room ListRoom Version: 6