| 16 Mar 2026 |
 eveeifyeve | * 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-4062916058 | 22:40:32 |
 alexfmpe | heh you barely missed 500k | 22:44:25 |
| 18 Mar 2026 |
 Alex | 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 | * 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 | Reproducer: https://gist.github.com/colemickens/78af9a28c01b888726322ca6628b27f5 | 02:30:29 |
| Alex | I went back to 22.05 and it still failed.
Did this ever work? | 04:00:56 |
| alexfmpe | no clue but I've also seen FFI define errors for a few months now when trying to build for other archs | 04:21:32 |
| alexfmpe | $ 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 | https://github.com/libffi/libffi/blob/master/src/loongarch64/ffitarget.h#L39
https://github.com/libffi/libffi/blob/master/src/riscv/ffitarget.h#L36 | 04:23:15 |
| alexfmpe | I 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.h | 04:24:25 |
| alexfmpe | * 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#L36 | 04:37:11 |
| alexfmpe | * $ 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 | * $ 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 | 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 | 04:49:25 |
| Alex | 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 | 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 | Not for native | 05:46:36 |
| alexfmpe | In reply to @alexfmpe:matrix.org
Not for native One is cross compiler ghc, the other is cross compiled ghc | 05:47:31 |
| Alex | Right, so haskellPackages.ghc is the same as buildPackages.ghc? | 05:48:13 |
| alexfmpe | 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 | In cabal packages that is | 05:50:24 |
| alexfmpe | haskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component | 05:50:54 |
| alexfmpe | So we have to manually break cycles for a bunch of test packages with dontCheck | 05:51:15 |
| alexfmpe | Search for 'cycle' or so in configuration-common.nix for examples | 05:51:40 |
| alexfmpe | `nix-build --show-trace` can help find specific cycles since it shows the call stack | 05:52:47 |
| alexfmpe | 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 | I'd expect haskellPackages.foo to always have the same host platform | 05:53:46 |
| alexfmpe | * I'd expect pkgsCross.foo.haskellPackages.bar to always have 'foo' as same host platform for all 'bar' | 05:54:28 |
| alexfmpe | But bar=ghc acts special | 05:54:53 |
| alexfmpe | 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 |
