[justincormack]

So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler?

Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.

[yiyus]

It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw...

Basically, you start from the last C version, and every version is supposed to be able to compile the next one.

[cperciva]

So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?

[sesutton]

You could audit the Go source and then use the diverse double compiling technique[0] to verify that the binary you're using corresponds to that source code.

[0] http://www.dwheeler.com/trusting-trust/dissertation/html/whe...

[cperciva]

You mean, audit a large number of independently-written Go compilers?

[indians_pro]

Nicely done. To be fair though, Go is just 6 years old and still evolving.

[cperciva]

Exactly. Which is why I think it's important to keep the option of compiling its compiler from a language which has a large diversity of compilers.

[f2f]

You can't avoid trusting trust. "Ken was here" :)

[sanxiyn]

You actually can. Proof here: http://www.dwheeler.com/trusting-trust/

[f2f]

I was alluding to Ken being the author of the old, as well as one of the authors of the new compiler. In jest :)

[cperciva]

You can. You just have to bootstrap all the way up.

[fugyk]

What if any intermediate version is found to contain the violation of trusting trust? Every go maintainer has to build every version sequentially from that version to current version.

[justincormack]

Ah ok, so there will be a pretty long chain from 1.2 eventually, but hopefully it will be part of the test suite...

[enneff]

You should always be able to build a Go 1.x compiler with just the 1.4 tool chain binaries. We have committed to sticking to the Go 1.4 language and libraries for the compiler tool chain.

[TheLoneWolfling]

Where is this fact documented? Are patches tested against 1.4 tool chain binaries?

[enneff]

> Where is this fact documented?

http://tip.golang.org/doc/install/source#go14

> Are patches tested against 1.4 tool chain binaries?

The builders build the tool chain with Go 1.4, so the build dashboard will show failures if a patch incompatible with 1.4 is submitted. (We have pre-commit trybots that do the same.)

[madhusudancs]

Here https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA...

In the proposal section.

[jlouis]

Usually you don't keep the chain. You just keep a working compiler. You can also bootstrap from another implementation of the language, e.g., gccgo.

A common trick is to keep a highly portable interpreted version of the target language and then use this for bootstrapping, but often you attack new architectures by cross-compilation instead. It all depends.

Also, it is common for self-hosting languages to require themselves to build.

[ori_b]

Either cross compile, or get the last C-based Go compiler, and use that to build the more recent Go releases.

[cbd1984]

> So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler?

What's the bootstrap process for the C compiler part of the compiler?

[4ad]

The is no C code in the compilers anymore.

[burnte]

But if one has access to the Go compiler source, is it not a reasonable guess that one would be able to access a go compiler binary from the same trusted source? I just don't see this as a problem since it is impossible to build a computer from the ground up without trusting a lot of software first.

[dmm]

Probably gccgo, which is included in gcc.

[dmm]

For the purposes of bootstrapping.