| 27 Apr 2025 |
 sterni (he/him) | Or as the document says:
So considering the two cases we identified at the top of the page:
- Building GHC as a cross-compiler - this is the stage 1 compiler
- Cross-compiling GHC itself - this is the stage 2 compiler
both of these cases are handled in the same way.
| 09:47:13 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @sternenseemann:systemli.org
GHC, in terms of cross really only has two variables when it comes down to it:
- stage0 you pass in and it has to be a native compiler.
- target: which sets the target for all GHCs produced by the build system.
This gives you, assuming you set target to be different from host:
- Stage0 builds Stage1. Stage1 is (host==build)->target, a cross compiler.
- Stage1 builds Stage2. Stage2 is target->target, a cross compiled native GHC.
So we don't have derivation for stage2 yet? | 09:50:49 |
| sterni (he/him) | Building a cross compiler (stage1) is largely unproblematic and works well with hadrian. Building Stage2 is much more problematic, precisely because it's treated as “just running stage1 again” which doesn't give many avenues for prescribing different tools, libs etc. I'm relatively sure that, for us, it just works because cc-wrapper checks the architecture of libraries before linking since GHC has no ability to differentiate the inputs. | 09:50:55 |
| sterni (he/him) | We have, what where you trying to build? | 09:51:07 |
| sterni (he/him) | * We have, what were you trying to build? | 09:51:12 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @sternenseemann:systemli.org
We have, what where you trying to build? a ghc bindist tarball that runs on loongarch64 of course | 09:51:41 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Generating the tarball just needs some cutoff before installPhase, so omit this now | 09:52:27 |
| sterni (he/him) | It would be nice if we could just pass in a stage0 cross compiler, but unfortunately libraries need to be built with stage1 (“So in order to use the stage 1 compiler to build libs-install, we must be able to run it”). I wonder whether this assumption could be eliminated eventually, compiler and libs are tied very closely together, but it would be nice if it'd work as long as you use the same version or something. | 09:53:14 |
| sterni (he/him) | specifically what derivation. | 09:53:32 |
| sterni (he/him) | * specifically what derivation? | 09:53:35 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @sternenseemann:systemli.org
specifically what derivation. Ideally pkgsCross.loongarch64-linux.haskell.compilers.ghc94 | 09:54:23 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | ghc984 | 09:54:32 |
| sterni (he/him) | That would set finalStage = Stage2 if the assert were removed. ghc94 would also do Stage2. | 09:57:52 |
| sterni (he/him) | Can't really tell you why you are seeing just stage1, though since you are obviously working on some kind of wip tree? | 09:58:28 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @sternenseemann:systemli.org
Can't really tell you why you are seeing just stage1, though since you are obviously working on some kind of wip tree? No, I'm working on nixpkgs master | 09:58:44 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @sternenseemann:systemli.org
That would set finalStage = Stage2 if the assert were removed. ghc94 would also do Stage2. I'm building the cross compiler, yes, just didn't know this can be changed | 09:59:31 |
 alexfmpe | I want to remove a lib.warn from a derivation, AFAICT that causes no rebuilds whatsoever so does it go to master so it gets merged back into staging-next and haskell-updates? | 11:31:05 |
| alexfmpe | * I want to remove a lib.warn from a derivation, AFAICT that causes no rebuilds whatsoever
should it go to master so that it gets merged back into staging-next and haskell-updates? | 11:31:22 |
 maralorn | A Haskell lib? | 11:36:30 |
| maralorn | imo you can do whatever you want. Small changes which cause little rebuilds are always allowed to go to master in our new paradigm. | 11:37:08 |
| maralorn | Merging to haskell-updates is always fine. | 11:37:27 |
 Alex | In reply to @aleksana:mozilla.org
Generating the tarball just needs some cutoff before installPhase, so omit this now Nixpkgs outputs can be used as is by using nix-copy-closure or nix copy to upload them to the target machine.
If you need a tarball, there is also nix-store --export or nix nar pack. | 13:19:23 |
| alexfmpe | huh I messed up and force pushed the remove warning to haskell-updates instead of to my branch but AFAICT was rebased properly so all that happened is I removed the warning directly on haskell-updates instead of doing a PR against it | 16:53:33 |
| maralorn | We have branch protection, so afaik you couldn't have pushed it if it wasn't a forward. | 17:11:08 |
| alexfmpe | I think the force bit in force push is lazy | 17:58:57 |
|  @denizalpd:matrix.org left the room. | 18:00:29 |
| 28 Apr 2025 |
|  chvp left the room. | 14:30:17 |
| 29 Apr 2025 |
|  ortolanbunting3002 joined the room. | 01:26:35 |
 woobilicious | man I'm having this super weird issue where typed-process in ghci via nix-shell has the Process type, but nix shell for my haskell script doesn't | 06:15:28 |
| Alex | In reply to @woobilicious:matrix.org
man I'm having this super weird issue where typed-process in ghci via nix-shell has the Process type, but nix shell for my haskell script doesn't Different Nixpkgs versions? | 07:03:34 |
