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
build: adopt Go 1.17 as bootstrap toolchain for Go 1.19 #44505
Comments
Actually, I confused myself while writing this. |
Being able to assume a recent compiler for bootstrapping would be really nice for not having to remember all the quirks of Go 1.4, or needing to worry about working around long-fixed issues. FWIW, OpenJDK appears to require the immediately previous release for bootstrapping (see https://openjdk.java.net/groups/build/doc/building.html, "Build JDK Requirements"), and also has a 6-month release cycle (https://en.wikipedia.org/wiki/OpenJDK#OpenJDK_versions), but building OpenJDK takes way longer than running make.bash does. I don't think we need to be nearly as aggressive at uprev'ing Go bootstrap versions, but I think it at least suggests end users could tolerate another uprev before 1.256. :) |
This is a good idea, however, perhaps it would make sense to additionaly declare that the bootstrap version of Go is also going to be the long term support or "LTS" version, which keeps receiving backports of bugfixes for 4 years (or whatever the support period for the bootstrap version is going to be). In some organizations and for some developments, having a stable LTS version that keeps receiving bug fixes is extremely valuable. |
FWIW, the level of aggressive bootstrap version bumps OpenJDK does are a big hurdle towards having recent OpenJDK packaged for backported distribution releases (and require a lot of extra coordination / "fancy footwork" from maintainers to coordinate or "hack" around). As a concrete example for Go, this could make adding new architectures more difficult for a distribution until/unless IMO this would be easier to understand/stomach if the proposed version were one that's already supported by at least the most recent |
Just a note that GCC 11 will support Go 1.16. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. |
This should be mentioned in the release notes for Go 1.18. And maybe even in the release notes for Go 1.17, if still possible? (since the removal of support for old macOS versions is usually noted one release note in advance) |
We missed implementing this for Go 1.18. We will shoot for bumping the minimum bootstrap toolchain in Go 1.19 instead. (The main concern with Go 1.17 was the stability of the register ABI, but that has been rock solid.) Thoughts? Concerns? Thanks. |
Change https://golang.org/cl/355690 mentions this issue: |
Before the 1.12 release the use of linkname did not prevent a compiler error for an empty function body (see #23311). Add some build tags so that cmd/link will build with earlier releases. It's true that we currently require Go 1.16 as the bootstrap compiler (#44505). But for this simple case keep things working with older compilers for now. Change-Id: I67fe021406096c64c01d6e2c9adbcc4388988a6e Reviewed-on: https://go-review.googlesource.com/c/go/+/355690 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Change https://golang.org/cl/369914 mentions this issue: |
… Go 1.4 Preparation for #44505, but safe for Go 1.18. Also fixes the default build on Macs, at least for people who have a $HOME/go1.17 or have run go install golang.org/dl/go1.17@latest go1.17 download Change-Id: I822f93e75498620fad87db2436376148c42f6bff Reviewed-on: https://go-review.googlesource.com/c/go/+/369914 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Building from source no longer works for me after this change:
I have Go 1.17.4 installed under /usr/local/go, but it still looks for go1.4 in my home directory. |
I'm experiencing the same thing on Arch (where I bootstrap with what's in Skimming the CL, Adding |
Change https://golang.org/cl/370138 mentions this issue: |
I am also seeing failures in a Google Cloud Build environment which effectively does |
Yeah I did that on my side too. Perhaps GOROOT_BOOTSTRAP should default to |
I'm pretty sure it was just an oversight (as the new code "reassigns" the variable to set it up); the behavior you're describing is the intended behavior (see #48155), and what it'd do with the missing |
Critically, note that The odd thing to me is why |
… back to Go 1.4" This reverts https://golang.org/cl/369914. Reason for revert: Breaking previously working toolchain builds. For #44505. Change-Id: I09ae20e50109a600d036358118077d27669df39c Reviewed-on: https://go-review.googlesource.com/c/go/+/370138 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
I sent https://golang.org/cl/370156 to restore the lost export of |
Dist can be run directly by hand too, in rare circumstances. But yes, the bug was the missing export. Thanks for finding it. |
Change https://golang.org/cl/370274 mentions this issue: |
… Go 1.4 Preparation for #44505, but safe for Go 1.18. Also fixes the default build on Macs, at least for people who have a $HOME/go1.17 or have run go install golang.org/dl/go1.17@latest go1.17 download Replay of CL 369914 after revert in CL 370138. Only change is adding 'export GOROOT_BOOTSTRAP' in make.bash. Change-Id: I8ced4e87a9dc0f05cc49095578b401ae6212ac85 Reviewed-on: https://go-review.googlesource.com/c/go/+/370274 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
I'm not sure whether or not this should be its own issue, but with the new code in Additionally, the checks are for explicitly the directories |
Retitled as suggested in #44505 (comment). |
Change https://go.dev/cl/386774 mentions this issue: |
For #44505 and #41184. Change-Id: I9503292dace1aa60de167ca5807bf131554465b9 Reviewed-on: https://go-review.googlesource.com/c/go/+/386774 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>
Change https://go.dev/cl/399514 mentions this issue: |
Updates #44505 Change-Id: I400110c33e69decf133fe9c4b582a450b7258b39 Reviewed-on: https://go-review.googlesource.com/c/go/+/399514 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Are we on track for 1.19? I see https://go-review.googlesource.com/c/go/+/386774/ was merged, but the builders still seem to bootstrap with Go 1.4.x from what I can see. |
I propose that starting with the Go 1.18 dev cycle, we require Go 1.16 as the Go bootstrap version (instead of Go 1.4).
When we switched to writing the Go compiler in itself, I wrote two proposals related to the bootstrap process.
The original proposal, https://golang.org/s/go13compiler (December 2013), was about the overall process of converting the compiler to Go.
In that proposal, I wrote:
This was all fairly hypothetical, and I certainly no longer believe it makes any sense to write a C back end for the Go compiler. (In fact, for the windows/arm64 port I did, I now have a working Go toolchain but still don't know what C compiler I'm supposed to use!)
The final proposal, https://golang.org/s/go15bootstrap (January 2015), simplified the process from an iterative one to hard-coding Go 1.4 as the bootstrap toolchain:
This was an important simplification, especially for people packaging Go for other systems. That decision has served us well.
But it has now been over six years since Go 1.4. Much has happened in the world of Go, and many bugs have been fixed. Many of the systems Go runs on today aren't supported by Go 1.4 (including darwin/arm64 for M1 Macs). Those are using newer toolchains to bootstrap, and the other systems could too. At a higher level, Go is far more mature and widely available now than it was in the Go 1.4 era. There are tons of available binary distributions to use for bootstrapping.
I propose that Go 1.17 be the last version of Go requiring Go 1.4 for bootstrapping, and that Go 1.18 require Go 1.16 for bootstrapping.
Go 1.16 would remain the bootstrap version for the next few years at least.
Why not Go 1.15?
//go:build
support. We don't want the compiler to have to keep using+build
even once the Go world has moved on. (Edit: this is only half true: see #44505 (comment).)Why not Go 1.17?
which would still work with Go 1.4.
(See next section.)
Why not Go 1.18?
Why not a quickly rolling version?
As noted above, I think it has served us well to have a fixed version required to build Go, as opposed to an automatically sliding version as originally envisioned. Packagers benefit from not having to update their package-building scripts to provide a different environment to each new Go release.
At the same time, bumping the version forward every five years or so lets us take advantage of newer Go capabilities and ports and to let us retire old compatibility shims (standard library packages like sort are carrying various +build'ed files to keep them building with Go 1.4). Modern C compilers are not written in pre-ANSI C.
What about a slow-rolling version?
That's essentially what this proposal would establish as our practice, although without a specific timeline.
The next obvious entry in the sequence after Go 1.4 and Go 1.16 is Go 1.256, followed by Go 1.65536.
(Or perhaps that is not quite the right pattern to establish.)
Using dates instead, assuming we switch to Go 1.16 in Go 1.18 (Feb 2022), it seems reasonable to me to revisit the bootstrap version four years later, which at our current release cycle would mean using Go 1.24 (Feb 2025) for Go 1.26 (Feb 2026).
But this proposal is not about establishing the sequence, which would depend on many other factors.
It is only about picking Go 1.16 as the bootstrap version starting in Go 1.18.
The text was updated successfully, but these errors were encountered: