IRC channel logs
2026-06-13.log
back to list of logs
<stabbles>Hi all, I had a lot of fun working on this project https://github.com/haampie/shpack, which provides a bootstrap path from the well-known binary seeds to GCC 4.7 with C and C++ compiler in 2 minutes and 30 seconds, natively for x86_64 and aarch64 (no cross step from 32-bit, which I can't even run on my laptop). It achieves this by using Frans <stabbles>Faase's MES-replacement repository, so the early C-compilers are all native instead of scheme, and TCC is immediately built with musl libc instead. Within ~45 seconds you have a pretty decent TCC + full musl libc. After that, it gets sequentially to `dash` + early `gmake`, at which point a Spack-inspired package manager takes over (I'm working on <stabbles>Spack). It has two nice properties: if you run `shpack install gcc` it resolves dependencies (it's very static) and computes a merkle hash for the install dir, and it generates a makefile. That makefile is what gives package level parallelism of the build until GCC and should speed up the build as I add more packages. <fossy>excellent work -- you have a lot of experiments in here that i wanted to experiment with in l-b but haven't found time <fossy>please tell me more about how you deal with dependencies particularly at the early stage? <stabbles>I think it's easier to mentally reverse-engineer it from `rootfs/tmp/shpack` than from reading the shell scripts. When a package.sh executes, it runs functions like `depends_on` and `patch`, which produces metadata in `/tmp/shpack`. Those files are input for the dependency resolver, which emits a Makefile from it. <stabbles>Thanks for live-bootstrap! I would not have even considered this to be possible otherwise ;) <xentrac>stux: wow, 2 minutes and 30 seconds! <aggi>and it doesn't need mes-libc either? <aggi>however, i do think the shpack will need a linux syscall abi inside /chroot <aggi>and this is what the x86_32 live-bootstrap would be needed for still, to do a full stage0 bootstrap without a linux syscall abi <aggi>since live-bootstrap supports both, a fully native stage0 and a stage0 bootstrap inside /chroot with linux kernel below <aggi>i think mes-replacement doesn't support both, not yet <aggi>"`shpack` bootstraps a basic, reproducible Linux environment natively from a few hundred bytes of binary seed" <aggi>git-clone complete. ok, good. but can it do so _without_ a running linux-kernel? <aggi>currently it is live-bootstrap for x86_32 _only_ which can "bootstraps a basic, reproducible Linux environment natively from a few hundred bytes of binary seed" <aggi>to my knowledge, all other variants can't; so please do not mis-lead with false premises <alganet>Still a nice achievement though. kernel bootstrap is a whole other beast that adds a lot of complexity, lots of people might not want it <alganet>the way I see it, kernel bootstrap can run in some machine somewhere and publish checksums. If someone else does it without bootstrapping the kernel and it matches, it's game <aggi>but the absense of kernel bootstrap impacts libc bootstrap too <aggi>hence the README.md is misleading, besides the statement made x86_32 wasn't necessary anymore <alganet>it's a gray area. Bootstrapping is traditionally associated with compilers only, so I would let it pass. The community has pushed for more (libc, kernel, no generated stuff), but those are arguibly recent ideas <alganet>for the common sense, it does bootstrap a linux environment! <alganet>I'm working on the kernel tower, and I see the project being useful. If I can get it to run on fiwix/linux-2, for example, it would be already a huge win that slots in nice <alganet>(I think mostly bubblewrap and sudo could be issues, but those can easily be worked around) <alganet>I'm excited for early dash, I need to investigate in detail how it was done. dash instead of bash-2 in the beginning sounds much simpler <xentrac>I agree that it's a gray area, and that ultimately you do want to avoid the dependency on the kernel <aggi>a full "system bootstrap" (including kernel) without "circular dependency" can be distinguished from a "language bootstrap" (or compiler bootstrap) <stabbles>Thanks for the feedback! Yes, it has a dependency on Linux, I do not have a use case to take it further to bootstrapping the kernel. "Linux environment" was meant to convey as much as "the basic software stack you expect on a Linux machine". What would you call it? <stabbles>To me "compiler bootstrap" sounds too narrow