| 25 Jul 2025 |
 teo (they/he) | should be actual compiler, I can rebase my patch for ghc-9.12 | 13:03:01 |
 MangoIV | In reply to @teoc:matrix.org
should be actual compiler, I can rebase my patch for ghc-9.12 I fear then it won’t apply to earlier versions. Building with ghc 9.10 but can only continue when my laptop is idle because while it’s building GHCs it’s unusable | 13:04:03 |
| MangoIV | 😌 | 13:04:07 |
| MangoIV | In reply to @mangoiv.:matrix.org
I fear then it won’t apply to earlier versions. Building with ghc 9.10 but can only continue when my laptop is idle because while it’s building GHCs it’s unusable Okay so applying the patch didn’t do anything, still doesn’t build, with the same error, cc teo (they/he) | 14:55:24 |
| teo (they/he) | thanks for looking! I'll look into this more at some point soon | 14:57:21 |
 maralorn | 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. | 23:24:27 |
| maralorn | But of course the error might be somewhere else. This has all so many moving parts and I am trying to learn the concepts. | 23:25:19 |
| 26 Jul 2025 |
 emily | buildPackages is pkgsBuildBuild | 01:56:32 |
| emily | packages that run on buildPlatform and target (when they are compilers) buildPlatform | 01:56:44 |
| emily | so buildPackages.ghc should not compile for WASM | 01:56:55 |
| emily | there are some weirdnesses here though because some packages are "a level up" | 01:57:07 |
| emily | e.g. stdenv is odd | 01:57:24 |
| emily | * e.g. stdenv.cc is odd | 01:57:36 |
| emily | agh! | 01:58:12 |
| emily | ok never mind I totally got my package sets mixed up. buildPackages is pkgsBuildHost :) | 01:58:22 |
| emily | pkgsBuildBuild is used to build things for the build platform, pkgsBuildHost for the host platform | 01:58:39 |
| emily | ("target platform" is only relevant from the perspective of a compiler. you should usually be talking about "build platform" and "host platform". from the perspective of pkgsFooBar.someCompiler, the consumer's Foo platform is the compiler's buildPlatform and hostPlatform, and the consumer's Bar platform is the compiler's targetPlatform. e.g. if you use pkgsBuildHost – buildPackages – in a package, and select a compiler from it, that compiler will have compiler's buildPlatform = your buildPlatform, compiler's hostPlatform = your buildPlatform, compiler's targetPlatform = your hostPlatform) | 02:00:15 |
| emily | well… hopefully all that made things more confusing | 02:00:28 |
| emily | anyway, it may be that the Haskell package set gets cross/splicing wrong in ways that make things weird. I've seen some hints of that in the past. not sure though | 02:00:50 |
 chreekat | so where does a cross compiler fit into that? (How do you specify Target?) | 04:34:15 |
 aidalgol | And then when I have a fix, do I create a PR to marge into haskell-updates? | 04:49:29 |
 Alex | In reply to @aidalgol:matrix.org
And then when I have a fix, do I create a PR to marge into haskell-updates? Yes | 07:27:06 |
| Alex | 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). | 07:40:16 |
| Alex | 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. | 08:00:57 |
|  oak 🏳️🌈♥️ changed their profile picture. | 08:27:13 |
| chreekat | Interesting article on cross compilation in nixpkgs if you haven't seen it https://blog.obsidian.systems/compiler-bootstrapping-in-nixpkgs/ | 08:54:04 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | 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/ Not cross compiling ghc though 😔 | 14:04:30 |
| chreekat | ...yet | 14:15:37 |
 sterni | maralorn: fyi https://github.com/NixOS/nixpkgs/pull/424162/commits/3ddc9cb90a53f999a1b0c3b4b7a6215973fa6df0 | 20:23:57 |
| sterni | we should cross compile some bindists before it stops being possible :p | 20:25:18 |
