In reply to @aidalgol:matrix.org
And then when I have a fix, do I create a PR to marge into haskell-updates?

Leaving out the confusing mess that is splicing, cross starts by setting buildPlatform and hostPlatform differently when initialising Nixpkgs.
Nixpkgs will then produce multiple "layers" of packages.
There are the top-level packages, which run on the host platform and (if applicable) target the host platform.
Under buildPackages i.e. pkgsBuildHost are packages that run on the build platform and (if applicable) target the host platform.
More rarely, you might need to use pkgsBuildBuild for compilers that target the build platform.
Finally, there is targetPackages i.e. pkgsHostTarget for when you're inside buildPackages and need to reference a top-level package.

So with WASM, pkgsCross.wasm32-unknown-none is the top-level layer that builds on your native system and runs on WASM.
pkgsCross.wasm32-unknown-none.ghc is a GHC cross-compiled to run on WASM.
pkgsCross.wasm32-unknown-none.buildPackages.ghc is a GHC cross-compiler that runs on your native system and targets WASM.
pkgsCross.wasm32-unknown-none.pkgsBuildBuild.ghc is a GHC that runs and targets your native system.
pkgsCross.wasm32-unknown-none.haskellPackages.pandoc is Pandoc compiled to run on WASM (i.e. compiled with buildPackages.ghc).

In reply to @maralorn:maralorn.de
I would like to conceptually grok how cross-compilation works in nixpkgs. My understanding is that "buildPackages" is meant to contain build outputs which are meant to be used on the build system, and they can be used to produce build outputs meant to be run on the target system. What I am wondering is this: When we want to cross-compile to wasm then we need to take a ghc which has wasm als compile target. But that ghc I think runs on the build system and thus belongs to buildPackages right? But when we replace the ghc in buildPackages with a wasm-targeting one, then those haskellBuildPackages are kinda broken because they should be compiled for and usable on the build plattform, so "replacing" the ghc is kinda wrong is it?

I am asking because I am trying to understand this line: https://github.com/ners/nix-wasm/blob/795efcfb8f8e98d7084be5da354cbe850f5834da/flake.nix#L48 Which works, but it does e.g. lead to ghcWithPackages not working for wasm cross.

buildPackages contains cross-compilers, so that line doesn't look too out of place.
I'm not sure what exactly the haskell.override is doing.
(In my experience, extending prev.haskell without override works, though I was redefining all of compiler and packages.)

The wasm32-wasi-ghc-9_12 doesn't have any passthru attributes, which Nixpkgs needs to do various things correctly.
The author has already realised this by adding targetPrefix to it, but there might be others needed to make ghcWithPackages work.

In reply to @b:chreekat.net
Interesting article on cross compilation in nixpkgs if you haven't seen it https://blog.obsidian.systems/compiler-bootstrapping-in-nixpkgs/

In reply to @sternenseemann:systemli.org
we should cross compile some bindists before it stops being possible :p

In reply to @teoc:matrix.org
Btw if there's issues the nixpkgs maintainers would like emphasized more, I'm happy to raise things at the GHC meetings. No guarantees that stuff will get prioritised but it might help avoid stuff falling through the cracks

In reply to @alex:tunstall.xyz
Do you know if anyone is looking into making cross work with Hadrian?
It would probably be far more effort than adding our own bindists to tarballs.nixos.org and is of limited benefit to x86 and aarch64, so I could understand if nobody wants to do it.

In reply to @alex:tunstall.xyz
Do you know if anyone is looking into making cross work with Hadrian?
It would probably be far more effort than adding our own bindists to tarballs.nixos.org and is of limited benefit to x86 and aarch64, so I could understand if nobody wants to do it.

In reply to @alex:tunstall.xyz
Do you know if anyone is looking into making cross work with Hadrian?
It would probably be far more effort than adding our own bindists to tarballs.nixos.org and is of limited benefit to x86 and aarch64, so I could understand if nobody wants to do it.

Maybe this https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11444 ?

Is there a specific set of issues you have in mind?

In reply to @teoc:matrix.org

Maybe this https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11444 ?

Is there a specific set of issues you have in mind?