| 16 Dec 2025 |
Randy Eckenrode | I think this is for the minimal bootstrap. | 12:18:14 |
K900 | Yeah but I don't know if it's easier to chain through glibc or musl | 12:18:35 |
K900 | And I'm saying there's no reason for it to specifically be musl | 12:18:43 |
K900 | If glibc is easier | 12:18:45 |
dramforever | maybe musl is easier to build with older gcc or something? why were we on musl anyway? | 12:20:21 |
helle (just a stray cat girl) | there are alternatives to musl that may be easier to wrangle, but I can't access my notes right now | 12:22:13 |
Alex | In reply to @dramforever:matrix.org maybe musl is easier to build with older gcc or something? why were we on musl anyway? I don't know much about the topic under discussion, but my guess is static linking. | 12:30:05 |
dramforever | interesting point | 12:34:14 |
Randy Eckenrode | Does static make it easier for a from-source bootstrap? | 12:35:13 |
Alyssa Ross | I would guess the much simpler and more portable code | 13:54:13 |
Alex | In reply to @reckenrode:matrix.org Does static make it easier for a from-source bootstrap? Unsure. Either way, you need to compile a libc right?
I thought this was about the existing bootstrap-tools, where it'd make sense to use static linking. | 13:58:28 |
aleksi | The musl build system is simpler than musl and has fewer dependencies afaik. For example we don't need Python in musl, which glibc does need. It might be feasible to build Python with mes-libc and avoid musl in that way, but mes-libc is pretty buggy. I'm curious if you all know of any alternative paths | 17:20:19 |
dish [Fox/It/She] | we need some sort of libc to build glibc, and it is way way way easier to build a gcc that targets musl then build glibc, then rebuild gcc to target glibc, than it is to use mes-libc or similar to build glibc and its deps | 17:49:33 |
dish [Fox/It/She] | thats what I was thinking of doing, that way we don't have to rebuild yet another GCC, and instead can just make a wrapper that passes the appropriate gcc flags to link to glibc instead. Plus, this gcc wouldn't be used in actual stdenv, its just used to build the stdenv tools, so using musl or gcc in bootstrap shouldn't matter, since the whole point of the early stdenv stages is to not have any bootstrap tools leaking into stdenv proper | 17:51:38 |
| 17 Dec 2025 |
aleksi | Ok, I think here's a gcc that targets glibc: https://github.com/NixOS/nixpkgs/pull/471642/changes/1f77d59c3450ac97333d9048dc13185ede164788 | 12:02:55 |
aleksi | It's not very thoroughly tested, but gcc and g++ both seemed to work with simple programs | 12:03:19 |
dish [Fox/It/She] | as much as I don't like doing this, we probably want to build all the bootstrap tools into a tarball at the end of it, that way we have a single blessed bootstrap path where all platforms get a tarball and busybox and go from there, and we're not special-casing platforms that use minimal-bootstrap into a different code path. | 17:45:32 |
dish [Fox/It/She] | Simplicity is the way to go here, after all | 17:45:38 |
K900 | Actually kinda disagree, I think it makes sense to cross-bootstrap the other platforms | 17:46:19 |
K900 | And then we can just have Nix handle caching | 17:46:27 |
dish [Fox/It/She] | sounds good to me | 17:46:40 |
dish [Fox/It/She] | as long as we have a single code path then that makes everyone's life better(even if that involves cross-building on non-minimal platforms) | 17:47:02 |
dish [Fox/It/She] | since stdenv doesn't need more complexity | 17:47:17 |
dish [Fox/It/She] | frankly it hurts my head sometimes lol | 17:47:22 |
| 18 Dec 2025 |
aleksi | Can we cross-bootstrap even the darwin platforms from Linux? | 08:58:00 |
K900 | No, Darwin needs its own bootstrap chain I think | 09:10:11 |
emily | that would also make Darwin development a pain | 11:37:05 |
Alex | Is it not already? | 12:05:38 |
Randy Eckenrode | Maybe once Darwin is switched to LLVM/LLD bintools. | 12:37:14 |
Randy Eckenrode | But it would still be painful without some way to emulate the Linux part. | 12:37:36 |