It is possible that Go 1.4.2 is not stable on Plan 9.

Could you try bootstrapping from the tip of release-branch.go1.4, or https://dl.google.com/go/go1.4-bootstrap-20171003.tar.gz ? This is the maintained version for bootstrapping, not 1.4.2. Thanks.

Thanks @cherrymui - I tried downloading and building Go from https://dl.google.com/go/go1.4-bootstrap-20171003.tar.gz into $home/go1.4, but the problem persists:

term% ./make.rc
Building Go cmd/dist using /usr/glenda/go1.4
Building Go toolchain1 using /usr/glenda/go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
unexpected fault address 0x720000008d
fatal error: fault
[signal 0x2 code=0x0 addr=0x720000008d pc=0x4a7e81]

goroutine 1 [running]:
runtime.gothrow(0xb7c9f0, 0x5)
	/usr/glenda/go1.4/src/runtime/panic.go:503 +0x8e fp=0x9640c98 sp=0x9640c80
runtime.sigpanic()
	/usr/glenda/go1.4/src/runtime/os_plan9.go:50 +0x1a5 fp=0x9640d00 sp=0x9640c98
bootstrap/cmd/compile/internal/ssa.BuildFuncDebug(0x93411e0, 0x9375340, 0x0, 0xd010f8, 0x1)
	/usr/glenda/go/src/cmd/compile/internal/ssa/debug.go:367 +0x19b1 fp=0x96411c0 sp=0x9640d00
bootstrap/cmd/compile/internal/gc.genssa(0x9375340, 0x972c460)
	/usr/glenda/go/src/cmd/compile/internal/gc/ssa.go:6141 +0x135c fp=0x9641630 sp=0x96411c0
bootstrap/cmd/compile/internal/gc.compileSSA(0x93742c0, 0x0)
	/usr/glenda/go/src/cmd/compile/internal/gc/pgen.go:308 +0x127 fp=0x9641708 sp=0x9641630
bootstrap/cmd/compile/internal/gc.compile(0x93742c0)
	/usr/glenda/go/src/cmd/compile/internal/gc/pgen.go:277 +0x2ed fp=0x96417b0 sp=0x9641708
bootstrap/cmd/compile/internal/gc.funccompile(0x93742c0)
	/usr/glenda/go/src/cmd/compile/internal/gc/pgen.go:222 +0x201 fp=0x9641828 sp=0x96417b0
bootstrap/cmd/compile/internal/gc.Main(0xd00cb8)
	/usr/glenda/go/src/cmd/compile/internal/gc/main.go:714 +0x39c4 fp=0x9641ee8 sp=0x9641828
main.main()
	/usr/glenda/go/src/cmd/compile/main.go:52 +0x1ca fp=0x9641f98 sp=0x9641ee8
runtime.main()
	/usr/glenda/go1.4/src/runtime/proc.go:63 +0xf8 fp=0x9641fe0 sp=0x9641f98
runtime.goexit()
	/usr/glenda/go1.4/src/runtime/asm_amd64.s:2232 +0x1 fp=0x9641fe8 sp=0x9641fe0

go tool dist: FAILED: /usr/glenda/go/pkg/tool/plan9_amd64/compile -std -pack -o /tmp/go-tool-dist-498300585/internal/cpu/_go_.a -p internal/cpu -importcfg /tmp/go-tool-dist-498300585/internal/cpu/importcfg -asmhdr /tmp/go-tool-dist-498300585/internal/cpu/go_asm.h -symabis /tmp/go-tool-dist-498300585/internal/cpu/symabis /usr/glenda/go/src/internal/cpu/cpu.go /usr/glenda/go/src/internal/cpu/cpu_amd64.go /usr/glenda/go/src/internal/cpu/cpu_x86.go: exit status: 'compile 3833: 2'
go tool dist: open /tmp/go-tool-dist-498300585/internal/cpu/_go_.a: '/tmp/go-tool-dist-498300585/internal/cpu/_go_.a' does not exist

FWIW, 1.4 is at least functional enough for go get github.com/golang/example/hello to result in a working hello world binary. It just doesn't seem capable of bootstrapping 1.14.3.

cc @0intro

Have you seen the bootstrapping instructions in https://github.com/golang/go/wiki/Plan9 ?

@millerresearch: No I hadn't, thanks - I was using the 9front FQA instructions. I'll take a look at the wiki, and try the instructions there.

I think you should try to bootstrap from a more recent Go distribution. More binary packages are available here.

... it seems to fail to bootstrap 1.13, 1.9, and 1.5 as well (and presumably every other version, those are just the ones I tested).

(I built go1.4 from the C sources, on AMD64)

I was able to build 1.5 by, effectively, brute forcing it.

1.4 panics building 1.14, but it has an entirely different issue with 1.5: it sporadically, non-deterministically encounters error in fork/exec: fd out of range / not open, at various stages in the process, which sometimes work.

while (! test -e ../bin/go) {
    make.rc
}

eventually works, but the easiest way I found was to split the build into multiple steps - first, build cmd/dist/dist, then run the bootstrap repeatedly until it succeeds, with -p 3.

Naturally, 1.5 has the same issue bootstrapping HEAD, 1.14, and 1.9 (plus others, most likely, these are again just the tested revisions), so it's very "fun" trying to get up to 1.14 natively.

Okay, here's what worked for me:

1.4 can build 1.5 and 1.7 without issue - but 1.5 cannot build HEAD. 1.7 can, however, so a viable bootstrap path remains: 1.4->1.7->1.14 :)

Other paths might work as well, this is what worked for me.

it's very "fun" trying to get up to 1.14 natively

By "natively", do you mean doing the first bootstrap step with a C compiler binary instead of a Go compiler binary? Because you trust the provenance of your C compiler more than the Go compiler binaries referenced above, or just because?

I'm not criticising: that's a reasonable thing to want to do. But it's problematic because go1.4 on Plan 9 is abandonware. There are serious bugs in its runtime which nobody has devoted the time to fixing, because they don't exist in more modern releases of Go, and they are the sort of intermittent bugs which are really tricky to diagnose.

The Plan 9 Go test builders don't use go1.4 for the bootstrap stage; they start with binaries for a later release. In order to make bootstrapping from go1.4 reliable, somebody would need to go back and fix the runtime. Any volunteers?

About the error in fork/exec, did that occur in go1.4 while compiling go1.5, or in go1.5 itself? If it's the latter, I think that could be fixed more easily: I think that's a known bug which was fixed in a later release of Go, so the correction could be back-ported to go1.5. Maybe open a separate issue for that?

1.4 can build 1.5 and 1.7 without issue

Don't be too confident. There are intermittent problems in go1.4 which can make it fail whatever it's trying to build.

There are intermittent problems in go1.4 which can make it fail whatever it's trying to build.

True; "with less issue than the other paths tried" is a more accurate phrasing.

We no longer use Go 1.4 for bootstrapping, so this issue is obsolete.