| 5 Apr 2025 |
 emily | but when you rebuild core parts of the toolchain, you need to do the bootstrap all over again | 09:20:58 |
 linj | In reply to @divyaranjan:matrix.org
Are the people from the Nix community? From Guix, 2-3 people have been trying to do this. @alex:tunstall.xyz has done some work | 09:22:47 |
 hellwolf | In reply to @emilazy:matrix.org
but when you rebuild core parts of the toolchain, you need to do the bootstrap all over again wouldn't you freeze the bootstrapped one to a git commit and never touch it again? | 09:27:09 |
| emily | let's say you build GHC 4 with Hugs compiled with GCC 14 | 09:27:42 |
| hellwolf | * wouldn't you freeze the bootstrapped one to a git commit (of guix pkg? or nixpkgs) and never touch it again? | 09:28:04 |
| emily | then when you bump GCC to 15, you need to build GHC 4 with Hugs compiled with GCC 15 | 09:28:08 |
| emily | ca-derivations would allow short-circuiting once you get to a bit-identical binary output, but that might never happen, e.g., because glibc store path changed | 09:28:10 |
| hellwolf | i see. i can see running old bin in a new container as a workaround | 09:29:19 |
 Divya | In reply to @emilazy:matrix.org
then when you bump GCC to 15, you need to build GHC 4 with Hugs compiled with GCC 15 Or, you just have Hugs be built with GCC 14? We always have multiple versions of GCC around. | 09:30:13 |
| emily | ok, but GCC 14 itself changed because glibc got updated | 09:31:08 |
| emily | it's true that you could pin an entire separate copy of Nixpkgs (and pay the evaluation cost for an entire separate package tree for everything that uses GHC, and then that multiplies because there are multiple bootstraped packages, etc.) | 09:31:34 |
| emily | at that point you're also multiplying the amount of source that needs to be trusted for the bootstrap too though | 09:31:51 |
| emily | and the compiler might have bugs on a certain architecture, or glibc with a new kernel, …, so you do not actually want to pin those things forever for the same reason you want to upgrade packages in general | 09:32:14 |
| Divya | Not sure about how it happens in Nixpkgs, but it's common in Guix to have it this way. The package tree gets evaluated only when built. I can create a package tree separate for GHC 9.2 to 9.12 without the previous package tree being affected. And if you need to change something later, you can always keep the older one separately in another package for that package tree. Maintenance is relatively easier. | 09:36:53 |
 toonn | So GHC 9.2 will link to whatever glibc was current back then forever? Or does this rely on grafting? | 09:37:56 |
 Alex | In reply to @divyaranjan:matrix.org
Are the people from the Nix community? From Guix, 2-3 people have been trying to do this. I don't think anybody's trying to boot from GHC 4's .hc sources here.
(My efforts are towards directly skipping to modern versions via MicroHs.)
One problem with the idea of building ancient GHC versions is that Nixpkgs prefers not to maintain equally old compatible compilers and libraries, so it may be a struggle to get it to work with the GCC versions we have available. | 10:28:27 |
| Divya | In reply to @toonn:matrix.org
So GHC 9.2 will link to whatever glibc was current back then forever? Or does this rely on grafting? We do have grafts, yes. | 10:34:30 |
 sterni | Thanks!! I'll properly review it soon. | 11:51:37 |
| sterni | With GHC there are probably more pressing issues at the moment, i.e. all the regressions from the Hadrian build system, figuring out how to bootstrap new platforms independently from GHC upstream etc. | 11:55:41 |
| sterni | bootstrapable GHC is impractical even if feasible because it would currently involve an insanely long bootstrap chain which is not workable with the build time we have available; also it would involve dealing with ancient LLVM versions at the very least for e.g. aarch64 | 11:57:28 |
| sterni | Divya: what problems are you running into with hadrian? We are basically treating it as a normal haskell tool, building it using the bindist we also use to bootstrap GHC and reusing our normal Haskell package set, this requires occasional fiddling with version constraints, but Hadrian is not too picky about dependency versions. | 11:59:30 |
| sterni | so basically we completely ignore the bootstrap plan thing upstream provides | 11:59:46 |
| sterni | you may be interested in https://github.com/stable-haskell/ghc/pull/3 for a future improvement; even some GHC devs are not happy with hadrian | 12:00:44 |
 Alyssa Ross | In reply to @sternenseemann:systemli.org
Thanks!! I'll properly review it soon. Thank you!! It's blocking me from updating Nixpkgs ATM so I hope it can be ready soon, but ofc if it ends up stuck for reasons outside of my control I can work around with an overlay or something | 13:10:37 |
 thirdofmay18081814goya | do we have hls 9.10 packaged somewhere? | 13:37:48 |
| thirdofmay18081814goya | or otherwise, what are the current options for getting 9.10? | 13:45:09 |
 maralorn | We use the same hls derivation for every ghc major version. | 13:45:16 |
| thirdofmay18081814goya | oh, do we have it somewhere in haskell.compiler.ghc910? | 13:46:23 |
| maralorn | It works. You can install ghc 9.10 with HLS from nixos-unstable. | 13:46:01 |
| maralorn | That’s the ghc you want. Have a look at the nixpkgs manual to read how to install hls for that. | 13:47:42 |
