| 5 Apr 2025 |
 Divya | Indeed. Someday I need to sit down and do the chain from Hugs. It's sad that Haskell hasn't taken care of this. | 08:44:49 |
| Divya | Have you guys talked to the GHC folks? | 08:45:05 |
 emily | it's not as simple as chaining from Hugs, people have tried but it requires a lot of patching to even start getting anywhere | 08:46:57 |
| Divya | In reply to @emilazy:matrix.org
it's not as simple as chaining from Hugs, people have tried but it requires a lot of patching to even start getting anywhere Are the people from the Nix community? From Guix, 2-3 people have been trying to do this. | 09:15:10 |
| emily | mostly not, since Nixpkgs has bigger bootstrapping issues :) | 09:15:36 |
| emily | (and though we might use complicated bootstrap chains to verify binaries, it's unlikely we'd put them into production, since chasing through a dozen GHC builds on every staging-next cycle would be too painful. I'm not sure how Guix copes with that kind of thing tbh) | 09:16:28 |
| Divya | In reply to @emilazy:matrix.org
(and though we might use complicated bootstrap chains to verify binaries, it's unlikely we'd put them into production, since chasing through a dozen GHC builds on every staging-next cycle would be too painful. I'm not sure how Guix copes with that kind of thing tbh) I don't think one has to necessarily do that. You'd only have to bootstrap a particular version from a previous one and then just "inherit" that for the next versions. | 09:19:44 |
| 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 |
