| 3 Sep 2025 |
 Winter | * i'm attempting to make a stdenv that uses an old (incompatible with our bootstrap tools) glibc -- i've tried to do things like "fake" cross to work around the issue, but always get stuck in some bootstrapping stage (either 3 or 4 depending on the strategy) because binutils from the previous stage still depends on new glibc, so e.g. expand-response-param can never get compiled. is my best bet for now to maybe create a custom stdenv that somehow bootstraps binutils from newer glibc -> older glibc? i can compile old glibc with new glibc but binutils is where it gets fun :/ | 15:16:53 |
| Winter | obviously the easiest route may be to just make bootstrap tools, but that'll require me downgrading to a nixpkgs rev and then probably get stuck in a bootstrapping-induced loop | 15:22:51 |
| Winter | not sure if i can even do this in one stage but replaceStdenv only lets me use one stage :-/ | 15:37:06 |
| Winter | guess i can make it let me use multiple | 15:37:13 |
| Winter | i suppose the ~nicest?? way to do it will be to modify stage1 (or add a stage between 0 and 1) to rebuild binutils | 15:48:53 |
| Winter | * i suppose the ~nicest?? way to do it will be to modify stage2 | 15:52:02 |
| Winter | but then you get stuck in another loop because xgcc is incompatible with old glibc... so then you can't even build another gcc or another xgcc | 19:01:56 |
| Winter | tried doing the cursed thing of:
build old glibc in stage2 build new xgcc in a subsequent stage, using the old xgcc's stdenv, but pointing to the old glibc as build sysroot use that xgcc like nothing has changed
but that also blows up, i guess expectedly | 19:46:01 |
| Winter | tried doing the cursed thing of:
build old glibc in stage2 build new xgcc in a subsequent stage, using the old xgcc's stdenv, but pointing to the old glibc as build sysroot use that xgcc like nothing has changed
but that also blows up, i guess expectedly | 19:47:15 |
| Winter | i guess there is really no nice way forward here lol | 19:47:30 |
| Winter | (i really don't wanna use an old nixpkgs!) | 19:47:37 |
| Winter | curiously, it also seems like my xgcc in between stages 2/3 and the binutils in stage4 can build at the same time?! | 19:52:01 |
| Winter | i have no clue how on earth that's possible | 19:52:46 |
 dish [Fox/It/She] | ugh why is our bootstrap not following the live-bootstrap build chain | 19:54:43 |
| Winter | 🤔 | 19:55:08 |
| Winter | 
Download image.png | 19:55:09 |
| dish [Fox/It/She] | talking about minimal-bootstrap which is fully from source and should be(but clearly isn't) following the build chain that live-bootstrap establishes | 19:56:12 |
| dish [Fox/It/She] | sorry if that was confusing | 19:56:26 |
| dish [Fox/It/She] | * sorry if that was confusing and/or not what you were talking about | 19:56:32 |
| Winter | it's not | 19:56:48 |
| Winter | i am talking about our normal bootstrapping process | 19:57:05 |
| Winter | perhaps minimal, if it actually works (last i heard it doesn't?), would be nicer for my crimes | 19:57:27 |
| dish [Fox/It/She] | it doesn't | 19:57:42 |
| dish [Fox/It/She] | im trying to fix and update it | 19:57:47 |
| dish [Fox/It/She] | * it doesn't afaik | 19:57:51 |
| dish [Fox/It/She] | so we can start the transition to using minimal-bootstrap as our regular bootstrap | 19:58:06 |
 emily | our thing isn't live-bootstrap | 20:14:50 |
| emily | live-bootstrap is a newer thing that goes via a billion OSes etc. | 20:14:58 |
| emily | our thing is the older Linux-only thing, I think based on the Guix chain | 20:15:09 |
| Winter | yep ^^ | 20:16:31 |
