compiling tip on macos 12.0.1 fails

[mfrw]

What version of Go are you using (go version)?

tip -> 6dcf83d

$ go version
go1.18-9e6ad46bcc

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mfrw/Library/Caches/go-build"
GOENV="/Users/mfrw/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/mfrw/g/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mfrw/g"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/mfrw/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/mfrw/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.18-9e6ad46bcc Sun Nov 7 04:57:22 2021 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mfrw/go/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/23/l301rzws12nc8ddzf0k3w5z00000gn/T/go-build885050090=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

./make.bash -v

What did you expect to see?

Building successfully

What did you see instead?

fatal error: runtime: bsdthread_register error

runtime stack:
runtime.throw(0x670d95)
        /Users/mfrw/go1.4/src/runtime/panic.go:491 +0xad fp=0x7ff7bfefefb0 sp=0x7ff7bfefef80
runtime.goenvs()
        /Users/mfrw/go1.4/src/runtime/os_darwin.c:104 +0x70 fp=0x7ff7bfefefc8 sp=0x7ff7bfefefb0
runtime.schedinit()
        /Users/mfrw/go1.4/src/runtime/proc.c:141 +0x5f fp=0x7ff7bfefeff0 sp=0x7ff7bfefefc8
runtime.rt0_go(0x7ff7bfeff020, 0x2, 0x7ff7bfeff020, 0x1000, 0x2, 0x7ff7bfeff260, 0x7ff7bfeff279, 0x0, 0x7ff7bfeff281, 0x7ff7bfeff287, ...)
        /Users/mfrw/go1.4/src/runtime/asm_amd64.s:95 +0x116 fp=0x7ff7bfefeff8 sp=0x7ff7bfefeff0
Building Go cmd/dist using /Users/mfrw/go1.4. ()
cmd/dist
fatal error: runtime: bsdthread_register error

runtime stack:
runtime.throw(0x670d95)
        /Users/mfrw/go1.4/src/runtime/panic.go:491 +0xad fp=0x7ff7bfefef60 sp=0x7ff7bfefef30
runtime.goenvs()
        /Users/mfrw/go1.4/src/runtime/os_darwin.c:104 +0x70 fp=0x7ff7bfefef78 sp=0x7ff7bfefef60
runtime.schedinit()
        /Users/mfrw/go1.4/src/runtime/proc.c:141 +0x5f fp=0x7ff7bfefefa0 sp=0x7ff7bfefef78
runtime.rt0_go(0x7ff7bfefefd0, 0x5, 0x7ff7bfefefd0, 0x1000, 0x5, 0x7ff7bfeff230, 0x7ff7bfeff249, 0x7ff7bfeff24f, 0x7ff7bfeff252, 0x7ff7bfeff260, ...)
        /Users/mfrw/go1.4/src/runtime/asm_amd64.s:95 +0x116 fp=0x7ff7bfefefa8 sp=0x7ff7bfefefa0

[seankhliao]

have you tried using a newer version of go than 1.4 to bootstrap?

[mfrw]

have you tried using a newer version of go than 1.4 to bootstrap?

I think go1.4 is the one which was in c and would be bootstrap-able. Please correct me if I am not correct.

[ALTree]

I think go1.4 is the one which was in c and would be bootstrap-able. Please correct me if I am not correct.

No, go1.4 is bootstrappable using a C compiler so it's what you need when compiling on a platform that currently has no Go support. But the only thing you need to bootstrap -in general- is a working Go version, and since we release binaries for your platform (darwin/amd64), you can just download the 1.17 binary from golang.org and use that to bootstrap tip. You don't need to build go1.4 from source with a C compiler.

Anyway this is #49425, except you're hitting it on go1.4. Closing as a dup of #49425.

[robohack]

So, what if one pedantically wants to bootstrap, from scratch (i.e. from nothing but a C compiler), on any modern machine such as macOS 12.x or newer, on which go-1.4 will no longer run?

Doesn't that mean we would have to somehow fix go-1.4 to get it working on these more modern platforms again?

I'm well aware of #44505 (and I applaud the progress there), but I also think #49425 wasn't really a very suitable place to discuss any bootstrap-from-scratch issues. Perhaps this is a better place?

[seankhliao]

The fix was a significant change, it would no longer really be 1.4 if the system call code changed.
In any case, you can use gccgo

[ianlancetaylor]

You can also bootstrap from C on Linux or any other non-macOS system that 1.4 supports, and then cross-compile. See src/bootstrap.bash.

[robohack]

Personally I wouldn't find it too hard to swallow the fact that changing even the whole runtime for a compiler would not necessitate changing its common public version identifier, provided of course that it would still produce the same output from the same input. It's really just a hidden fix -- it literally shouldn't change the outward behaviour of the code in any measurable way that matters.

On the other hand, bootstrapping by using a cross-compiler isn't too outlandish either (though it is tremendously more difficult to automate), made slightly better if the cross compiler can run in a virtual machine (though that is only slightly less difficult to automate). Indeed if only macOS were one of those platforms that better supported virtualization it would then even make it easier to cross-compile from a bootstrap running on an older version of itself.

I'm not sure which feels more the orphan here -- in some ways it feels like macOS is orphaned by the Go bootstrap compiler chain; even though in literal terms it is actually macOS that orphaned the compiler chain. I guess with my preferred environment actually being NetBSD it seems like the whole situation is absurd and should never have even been possible and both Go and macOS have failed to play strictly by the rule book!