Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bootstrappable Builds

bootstrappable.org

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Bootstrappable Builds

#11

Post by jcranmer »

er4hn wrote: post #2

The big issue with bootstrappable builds is how to get started and have good examples. This is an ambitious goal, like landing on the moon, and takes a lot to get there. My understanding of this has been you need to (a) Be able to have a compiler that can be compiled from understandable code, which itself may require a set of increasingly complex compilers. I've heard this referred to before as a "compiler pilgrimage…

I feel like the biggest issue of all is that bootstrappable builds are by and large solving the wrong problem. The main concern of bootstrapping is the existence of packages that require on older version of them to build themselves, because if you end up skipping a version for whatever reason, you may end up without a clear way forward (this isn't a theoretical concern--Debian gradle packaging is horribly broken because of this, and they've been trying for years without success to fix it).

When you have a build dependency on one of multiple stage 0 compilers, the problem of a cycle basically disappears. You need a C++ compiler to build a C++ compiler these days, but you have your choice of two C++ compilers, so the probability you wake up one day without a working C++ compiler that you need is quite low. And the mostly theoretical trusting-trust problem basically disappears on the second stage 0 compiler availability, so the marginal benefit of a third or fourth or nth stage 0 compiler is basically nil.

And yet, the vast majority of bootstrappable build efforts are basically focusing on "how do I go from, say, a hex editor to a working C compiler," which is one of the least useful efforts imaginable. You can sort of see this with their project list: they highly tout their efforts to get to gcc from "stage0", and when they start talking about Java, it instead becomes "here's how to build a 20-year old version of Java, but, uh, most of this stuff is unmaintained so good luck?" And the JVM languages are in a state of "uhhh... we don't know how to break these cycles, any ideas?"

Re: Bootstrappable Builds

#12

Post by jcranmer »

transpute wrote: post #9

> Current versions of GCC are written in C++, which means that a C++ compiler is needed to build it from source. GCC 4.7 was the last version of the collection that could be built with a plain C compiler, a much simpler task. Which C++ compiler was used to build GCC 4.8?

GCC 4.8 requires a C++98 compiler, which gcc 4.7 is.

Re: Bootstrappable Builds

#13

Post by kragen »

nine_k wrote: post #8
ryan77627 wrote: post #5

Earlier quoted context omitted.

Yeah pretty much, the best example I have found for showcasing a solution to this issue is this[1] example, where you can see we start from the most basic of "compilers" (quite literally the equivalent to a `sed` command) and work our way up to Linux 4.9 if I remember correct. Biggest issue is circular dependencies (a lot of lower level build tools depend on themselves nowadays, so we end up needing to build like 4-5…

> To avoid using an existing toolchain, we need some way to be able to compile a GCC version without C. We can use a less well-featured compiler, TCC, to do this. And so forth, until we get to a fairly primitive C compiler written in assembly, cc_x86 I imagined going a slightly different route. A minimal Forth can be written in assembly and in itself. It suffices to write a console using a serial port, a primitive FA…

i think this is a good approach, but almost everyone who has tried it has gotten bogged down in the usual problems with forth, where you get distracted by writing clever code instead of writing fairly boring, straightforward code that gets the job done in a dumb way. and where things fail in difficult-to-debug ways, so you spend a lot of time debugging. virgil dupras's duskos is the only candidate for an exception to this rule. hopefully you will write a second one!

Re: Bootstrappable Builds

#14

Post by nine_k »

kragen wrote: post #13
nine_k wrote: post #8

Earlier quoted context omitted.

> To avoid using an existing toolchain, we need some way to be able to compile a GCC version without C. We can use a less well-featured compiler, TCC, to do this. And so forth, until we get to a fairly primitive C compiler written in assembly, cc_x86 I imagined going a slightly different route. A minimal Forth can be written in assembly and in itself. It suffices to write a console using a serial port, a primitive FA…

i think this is a good approach, but almost everyone who has tried it has gotten bogged down in the usual problems with forth, where you get distracted by writing clever code instead of writing fairly boring, straightforward code that gets the job done in a dumb way. and where things fail in difficult-to-debug ways, so you spend a lot of time debugging. virgil dupras's duskos is the only candidate for an exception to…

I see. I would keep the Forth code to a minimum necessary to implement simple things, with an emphasis on things being understandable and hence auditable. Smart code is good; clever, bad.

Re: Bootstrappable Builds

#15

Post by nine_k »

tomatocracy wrote: post #10
nine_k wrote: post #8

Earlier quoted context omitted.

> To avoid using an existing toolchain, we need some way to be able to compile a GCC version without C. We can use a less well-featured compiler, TCC, to do this. And so forth, until we get to a fairly primitive C compiler written in assembly, cc_x86 I imagined going a slightly different route. A minimal Forth can be written in assembly and in itself. It suffices to write a console using a serial port, a primitive FA…

This[0] repo which has the stage0 code used by GPs linked repo includes some explanation in the README about why not Forth or Lisp - in summary it turned out to be harder than that, at least for the authors of that project. 0. https://github.com/oriansj/stage0

This is pretty interesting. But the author sets a much more difficult goal:

> the goal of creating a bootstrapping path to a C compiler capable of compiling GCC, with only the explicit requirement of a single 1 KByte binary or less.

Iä! I would not limit the size drastically, but would emphasize simplicity and legibility, in hopes that achieving correctness this way would be easier.

Re: Bootstrappable Builds

#16

Post by kragen »

nine_k wrote: post #14
kragen wrote: post #13

Earlier quoted context omitted.

i think this is a good approach, but almost everyone who has tried it has gotten bogged down in the usual problems with forth, where you get distracted by writing clever code instead of writing fairly boring, straightforward code that gets the job done in a dumb way. and where things fail in difficult-to-debug ways, so you spend a lot of time debugging. virgil dupras's duskos is the only candidate for an exception to…

I see. I would keep the Forth code to a minimum necessary to implement simple things, with an emphasis on things being understandable and hence auditable. Smart code is good; clever, bad.

easier said than done; i look forward to seeing your code ;)

Re: Bootstrappable Builds

#17

Post by kragen »

nine_k wrote: post #15
tomatocracy wrote: post #10

Earlier quoted context omitted.

This[0] repo which has the stage0 code used by GPs linked repo includes some explanation in the README about why not Forth or Lisp - in summary it turned out to be harder than that, at least for the authors of that project. 0. https://github.com/oriansj/stage0

This is pretty interesting. But the author sets a much more difficult goal: > the goal of creating a bootstrapping path to a C compiler capable of compiling GCC, with only the explicit requirement of a single 1 KByte binary or less. Iä! I would not limit the size drastically, but would emphasize simplicity and legibility, in hopes that achieving correctness this way would be easier.

legibility is a lost cause in the case of the binary seed anyway, so you might as well shoot for more simplicity. https://github.com/oriansj/bootstrap-seeds/blob/4715ae5292a6... is down to 512 bytes, and it's clearly possible to go further than that
Post reply on HN