proposal: doc: document that Go 1.14 is last to support darwin/386?

[bradfitz]

macOS Catalina does not support running 32-bit apps.

Time to remove darwin/386 support soon? (@rsc always liked keeping it around as an easy way to hack on the 386 port on his laptop, but sounds like that reason is going away. We might even be able to remove it earlier, once Russ upgrades his laptop.)

Might be worth noting that it's going away soon in the Go 1.14 release notes.

[dmitshur]

an easy way to hack on the 386 port

Does hacking on a port require being able to run the binaries, or just test that it compiles? If the latter, it'll still be possible to use something like linux/386 as a cross-compile target. (If the former, then that ability goes away when using macOS 10.15 or newer as this proposal stated.)

I opened a related proposal #34751 that's about darwin/arm.

[bcmills]

keeping it around as an easy way to hack on the 386 port on his laptop

That sounds like a good use-case for virtualization..?

[dmitshur]

Brad, do you have an idea of the benefits of removing darwin/386? Alternatively, what are the costs of keeping it? I'm aware of:

• needing to have builders for it
  • keeping them functional (human time)
  • executing Go tests with them (CPU time)
• some amount of code to maintain and keep tests passing
  • do you know how much there is? is likely to be similar in amount as CL 199499?

Anything I'm missing?

Asking these questions in order to have more information and to be able to evaluate this proposal better.

[bradfitz]

Yes,

• builder time (and we have very limited Mac resources, so I'd prefer to not waste their time on ~useless build configs)
• code size (less code is better)

It's much less code & less weirdness than nacl. At least these files:

./runtime/rt0_darwin_386.s
./runtime/cgo/gcc_darwin_386.c
./runtime/signal_darwin_386.go
./runtime/defs_darwin_386.go
./runtime/sys_darwin_386.s
./debug/macho/testdata/gcc-386-darwin-exec
./debug/macho/testdata/fat-gcc-386-amd64-darwin-exec
./debug/macho/testdata/clang-386-darwin.obj
./debug/macho/testdata/clang-386-darwin-exec-with-rpath
./cmd/vendor/golang.org/x/sys/unix/zsyscall_darwin_386.1_11.go
./cmd/vendor/golang.org/x/sys/unix/asm_darwin_386.s
./cmd/vendor/golang.org/x/sys/unix/zerrors_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/syscall_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/zsyscall_darwin_386.s
./cmd/vendor/golang.org/x/sys/unix/zsysnum_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/zsyscall_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/ztypes_darwin_386.go
./syscall/asm_darwin_386.s
./syscall/zerrors_darwin_386.go
./syscall/syscall_darwin_386.go
./syscall/zsyscall_darwin_386.s
./syscall/zsysnum_darwin_386.go
./syscall/zsyscall_darwin_386.go
./syscall/ztypes_darwin_386.go

But also stuff in debug/macho, cmd/link, etc.

So, there are non-zero costs.

What are the reasons to keep it? The one reason we had is going away in the next ~month (when our primary runtime/compiler people update their laptops).

And in a couple more years it won't even be possible to run a darwin/386 binary on any supported Go build.

[bradfitz]

We discussed this today in the Go runtime & compiler meeting and nobody had any objections against removing it in Go 1.15, documenting that Go 1.14 will be the last to include it.

[gopherbot]

Change https://golang.org/cl/202018 mentions this issue: doc/go1.14: announce upcoming removal of darwin/386 port