| 18 Mar 2026 |
 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 |
