Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bradfitz opened this issue Oct 7, 2019 · 6 comments
Closed

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

bradfitz opened this issue Oct 7, 2019 · 6 comments

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Oct 7, 2019

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.

@bradfitz bradfitz changed the title doc: document that Go 1.14 is last to support darwin/386? proposal: doc: document that Go 1.14 is last to support darwin/386? Oct 7, 2019
@gopherbot gopherbot added this to the Proposal milestone Oct 7, 2019
@dmitshur
Copy link
Contributor

dmitshur commented Oct 7, 2019

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
Copy link
Contributor

bcmills commented Oct 7, 2019

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
Copy link
Contributor

dmitshur commented Oct 7, 2019

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
Copy link
Contributor Author

bradfitz commented Oct 7, 2019

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
Copy link
Contributor Author

bradfitz commented Oct 8, 2019

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
Copy link
Contributor

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

@golang golang locked and limited conversation to collaborators Oct 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants