The half strap: self-hosting and Guile | Hacker News Reader

The half strap: self-hosting and Guile

wingolog.org

82 pointsepsylon10 comments

I've built the new Guile from source a handful of times now. It's definitely a slow process, but I'm very grateful that Guile doesn't require an older version of itself in order to build like a lot of other self-hosted languages. Self-hosting is good, but it's imperative that users can bootstrap on their own so that they don't have to place trust in a pre-built binary of the compiler in order to build the compiler. For example, Go has a self-hosted compiler now, but you don't need to trust a pre-built Go compiler binary to build Go, because you can bootstrap it using gccgo.

It's the same (or worse?) with Java. OpenJDK 6 and 7 can both be bootstrapped with GCJ, but with JDK 8 you need JDK6. Even GCJ needs a prebuilt jar of ECJ, so there is no way to bootstrap Java without having to trust binaries.

I kind of like the Go approach to this. (i.e. a fixed bootstrapping version that is compilable from c.) It's easy to identify what you need to bootstrap and doesn't absolutely require bootstrapping every time you compile. (i.e. you should be able to build the next go with 2 compiles once you're through the initial bootstrap rather than 3)

It's good that it doesn't require it, but it sounds like it would be nicer if the Guile build system offered the option of using a trusted build of the compiler to compile itself, if you have one lying around.

It does. You can set the GUILE_FOR_BUILD environment variable.

I like Chicken Scheme's take on this. Since Chicken's compiler always generates C code, which is then compiled by GCC (or Clang), one just releases both the source and the compiled scheme files(which are C sources).

Then, it's just "make" as usual.

I've even used this strategy to run a scheme program on iOS, trivially. You just have to ask it to stop at the C code generation and not invoke the C compiler. You then insert both chicken's C code and your program's in the xcode project, and call libchicken's initialization code from Objective-C. And then compile the whole blob with clang.

EDIT: :%s/compiled C/compiled scheme/g

>like Chicken Scheme's take on this. Since Chicken's compiler always generates C code, which is then compiled by GCC (or Clang), one just releases both the source and the compiled C files.

Shipping a pre-built binary is what Guile purposely doesn't do to avoid the trust issue. Chicken's technique doesn't cut it.

Sorry, my bad. I said "compiled C files" when I meant said "compiled scheme files", which are C sources, not binaries.

They are binaries, effectively. They are not source code, just like minified JavaScript code is not source code. Thanks for pointing this out to me. I work on a package manager with a Chicken package where this sort of thing is unacceptable, so I've filed a bug.

Does anyone who works on Chicken know how bootstrap it?

You may want to ask on the chicken-users list (chicken-users@nongnu.org, subscribe at https://lists.nongnu.org/mailman/listinfo/chicken-users). The current list of maintainers is at (http://wiki.call-cc.org/maintainers), you could also contact them directly. Or on free node's #chicken

Now, the C source is not included in the repository itself, so if you are (somehow) building from that(for instance, you already have a working chicken), you are ok. They are only included in the "release tarballs".

How does your package manager get around bootstrapping compilers, in general? Guile's approach requires maintaining a one-shot interpreter/compiler in C, that's only ever used once. I don't think all projects do that.

Reply on news.ycombinator.com