Bootstrappable builds: how and why [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Bootstrappable builds: how and why
[LWN subscriber-only content]
Welcome to LWN.net
The following subscription-only content has been made available to you<br>by an LWN subscriber. Thousands of subscribers depend on LWN for the<br>best news from the Linux and free software communities. If you enjoy this<br>article, please consider subscribing to LWN. Thank you<br>for visiting LWN.net!
By Jake Edge<br>August 17, 2026
FOSSY
This year's edition of the Free and Open<br>Source Software Yearly conference, better known as "FOSSY", moved north to the<br>beautiful (and enormous) campus of the University of British Columbia (UBC)<br>in Vancouver, Canada from its home for the three previous editions:<br>Portland, Oregon, in the US. There were many different types of talks at<br>FOSSY, from deeply technical kernel-track topics, through talks on legal<br>and community issues, to the "FOSS in Daily Life" talks. In the "Toolchains<br>and Other Development Tools" track, Timothy Sample gave a presentation<br>about bootstrappable builds,<br>which is somewhat less well-known than its cousin, reproducible builds, though LWN<br>did look at the topic just over two years<br>ago. In short, a bootstrappable build is one that starts with a tiny<br>program that can build another slightly larger program, which can build yet<br>another, and so on, until the entirety of a modern Linux user space is<br>built from a small seed. Ultimately, it results in code with a<br>completely understood origin—unlike a typical Linux user space today.
He began by asking attendees whether they had heard of bootstrappable builds<br>and whether they were generally familiar with the idea; he seemed impressed<br>that the majority knew the term and that roughly half of the audience knew<br>more than that. He said that he embarked on the path toward<br>bootstrappable builds almost ten years ago when he started using GNU Guix (which he pronounced<br>"geeks"—surprising me). At that time, if you<br>were using Guix, you were contributing to it, he said with a chuckle. Guix is a<br>"functional package<br>manager" that is similar to (and inspired by) Nix.
For both Guix and Nix, all of the software in the system is represented in<br>a "derivation graph", which describes how to build each of its<br>programs. There are various inputs required in order to be able to build a<br>particular program, which are specified in the graph. The way to build<br>each of the inputs (and, of course, the inputs to the inputs and so on) is<br>also represented in the graph. "There's hundreds and hundreds of nodes<br>in modern software, which is terrifyingly complex."
He gave the example of a Python program. It, obviously, requires Python in<br>order to run, but Python is a C program, so a C compiler is needed.<br>That C compiler is written in some language, so a compiler for that<br>language will be needed. And so on. Guix collects all of that into the<br>graph, which is an object that can be looked at and explored. "So you<br>start wondering who compiles my compiler's compiler compiler and where does<br>it stop?"
For a system like Debian, it stops at a C compiler binary that someone has<br>uploaded to the repositories. For Guix, the original stopping point was<br>a 250MB statically linked blob of GNU user-space programs. The answer to<br>where all of that code came from is not entirely clear, of course, which was<br>unsatisfying to Guix developers. That blob could be built reproducibly,<br>which is good, Sample said, but does not solve the entire problem.
Bootstrappable
The basic idea behind bootstrappable builds is to create a system that can<br>be built without relying on pre-built artifacts. "Can we go from zero<br>to the modern day without having to just assume the existence of these<br>already-built-for-us artifacts?" The classic recipe for yogurt<br>requires some yogurt to start the process, which is like how we normally<br>build a C compiler today—we start with an existing C compiler binary. You<br>might think about making sourdough bread with your grandmother's starter<br>brought over from the old country; "we're basically making C compilers<br>with Dennis Ritchie's starter carried over from Bell Labs".
It is not just C, of course, as it is true for most languages. It is<br>something of a point of pride for languages to "self host" by writing the<br>compiler and other tools in the language itself. It is natural for the<br>language developers to do that, because<br>obviously their language is the best, but it leaves something of a<br>chicken-and-egg problem behind. Bootstrappable builds is an effort to move<br>beyond that and to build these tools "from scratch".
Reproducible builds allow people to "have more confidence that the<br>binary you are using, which is actually executing on the computer,<br>corresponds to the source code". A user can receive a binary that<br>purports to come from a set of source code...