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

runtime: time fix for macOS Sierra Beta 4 #16579

Closed
bradfitz opened this issue Aug 2, 2016 · 16 comments

Comments

Projects
None yet
8 participants
@bradfitz
Copy link
Member

commented Aug 2, 2016

We probably want to include the macOS Sierra Beta 4 time fix in Go 1.7 final, despite claiming that rc4 was the last change.

Unfortunately we found out about the Beta 4 kernel change about 15 minutes after releasing rc4. :(

Original bug is: #16570
CL is https://golang.org/cl/25400 (2da5633)

/cc @ianlancetaylor @adg @quentinmit for thoughts.

@bradfitz bradfitz added this to the Go1.7Maybe milestone Aug 2, 2016

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

+1, I think we should release 1.7rc5 (possibly just for darwin?) today to get it in front of people, and then release final on Mon or Tue.

@broady

This comment has been minimized.

Copy link
Member

commented Aug 2, 2016

Uploading any rc5 binary clears out rc4 from the dl page, so we'd want to make binaries for every platform.

@adg

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

rc5 ~now SGTM.

On 3 August 2016 at 07:05, Chris Broadfoot notifications@github.com wrote:

Uploading an rc5 clears out rc4 from the dl page, so we'd want to make
binaries for every platform.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16579 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDile2Rzy9tFgSStEAfoFTe4BBEiN2Eks5qb7D-gaJpZM4JbA54
.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

Yes, I think we should make an rc5, unfortunately. Sorry.

We should also consider making a 1.4.4 release with this fix, unfortunately, so that people can bootstrap from source. But not until there is a final release of Mac OS Sierra.

@broady

This comment has been minimized.

Copy link
Member

commented Aug 3, 2016

@DomT4

This comment has been minimized.

Copy link

commented Aug 3, 2016

Hey folks, apologies for following up on this. We've had a couple of issues reported to us at Homebrew, at least the first of which looks related, unsure on the second.

It's something we didn't have any reports of before the most recent stable release & the most recent couple release candidates for 1.7. Our data seems to back that up; there's a jump of ~40 daily Go build failures on 10.12 to 190 yesterday.

Is there any chance at all of a 1.4.4 release being pushed up? Completely understand if the answer is no.

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2016

@DomT4, we're going to wait to do a 1.4.4 until macOS Sierra is officially released.

But in the meantime Homebrew could (and should) do a local patch, if that's possible.

You'd just make this part of 1.4:
https://github.com/golang/go/blob/release-branch.go1.4/src/runtime/sys_darwin_amd64.s#L142-L153

Look like this part of 1.7:
https://github.com/golang/go/blob/release-branch.go1.7/src/runtime/sys_darwin_amd64.s#L156-L173

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2016

@DomT4 Could you explain a little more about your build process? Do you always build a copy of Go 1.4 first before building 1.7?

@DomT4

This comment has been minimized.

Copy link

commented Aug 3, 2016

@quentinmit Sure, no worries.

We can't presume there's a suitable go on the system and in the $PATH for the bootstrap process already so we fetch either the precompiled go 1.4.2 or 1.4.3 from golang's servers:

  resource "gobootstrap" do
    if MacOS.version > :lion
      url "https://storage.googleapis.com/golang/go1.4.3.darwin-amd64.tar.gz"
      sha256 "c360f195b6bc0eeb4ebd4d590e5a11be830ebb11f28eaa2da107047a8cae4c24"
    else
      url "https://storage.googleapis.com/golang/go1.4.2.darwin-amd64-osx10.6.tar.gz"
      sha256 "da40e85a2c9bda9d2c29755c8b57b8d5932440ba466ca366c2a667697a62da4c"
    end
  end

That gets untarred into buildpath/"gobootstrap" where buildpath is something like tmp/go-20160803-56029-1fdnf2a, and GOROOT_FINAL & GOROOT_BOOTSTRAP are set to point there.

We then rebuild the precompiled package (this feels possibly redundant), cd into the src directory for either the 1.6.3 or 1.7rc5 release depending on which one the user requested, reset the GOROOT_FINAL env to point to our libexec & build from source.

After that's complete the bootstrap is removed & everything remaining installed into HOMEBREW_PREFIX/Cellar/go/<version>/libexec, with the executables go, gofmt & godoc symlinked into bin.

The code blob for that process in the formula is:

blob

    # GOROOT_FINAL must be overidden later on real Go install
    ENV["GOROOT_FINAL"] = buildpath/"gobootstrap"

    # build the gobootstrap toolchain Go >=1.4
    (buildpath/"gobootstrap").install resource("gobootstrap")
    cd "#{buildpath}/gobootstrap/src" do
      system "./make.bash", "--no-clean"
    end
    # This should happen after we build the test Go, just in case
    # the bootstrap toolchain is aware of this variable too.
    ENV["GOROOT_BOOTSTRAP"] = ENV["GOROOT_FINAL"]

    cd "src" do
      ENV["GOROOT_FINAL"] = libexec
      ENV["GOOS"]         = "darwin"
      ENV["CGO_ENABLED"]  = build.with?("cgo") ? "1" : "0"
      system "./make.bash", "--no-clean"
    end

    (buildpath/"pkg/obj").rmtree
    rm_rf "gobootstrap" # Bootstrap not required beyond compile.
    libexec.install Dir["*"]
    bin.install_symlink Dir["#{libexec}/bin/go*"]
@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2016

Thanks for the explanation. If you're willing to download a binary, then you might as well just download the 1.7rc5 binary instead. You can use that to successfully build the 1.7rc5 source on 10.12.

@DomT4

This comment has been minimized.

Copy link

commented Aug 3, 2016

We like to build the final installation (of the most recent stable/devel) go from source, but we don't have a major objection to using a binary for the sake of bootstrapping.

How backwards compatible with older OS X systems are the newer Go releases? As far as any user has told us we're still able to build the latest Go releases for 10.6 & up using the Go 1.4.3/1.4.2 binaries for bootstrapping. Will that change at all if we use 1.6.2 to bootstrap 1.6.3 & 1.7.5rc5 to bootstrap 1.7.5rc5?

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2016

The binaries are exactly as compatible as the source release; if the source release runs on the older OS X, the binaries will too. That said, we currently only promise backwards compatibility through 10.8. I don't think we've done anything to explicitly drop support for 10.6-10.7, but it might break without warning. (But that would also make source builds break.)

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2016

We only support OS X 10.8+ as of Go 1.6.

@DomT4

This comment has been minimized.

Copy link

commented Aug 3, 2016

Thanks @bradfitz & @quentinmit. I'll look into using a more recent binary to handle bootstrapping & discuss raising our minimum requirement for installation to 10.8 with the rest of the team so we're not potentially shunting undesired support work upstream to you IRT 10.7/10.6. Appreciate the feedback here.

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2016

Oh, and I'll mention that you don't need to do an extra rebuild of the binary package. The process of building Go already involves two builds. (Once to build the new Go with the old compiler, and then again to build the new Go with the new compiler.)

DomT4 added a commit to DomT4/homebrew-core that referenced this issue Aug 3, 2016

go: limit to 10.8 & above.
Upstream don't test or support anything less than 10.8 at this point. There are
a "known" 141 installations below that out of 45k, so doesn't seem to be huge
demand.

Ref: golang/go#16579

DomT4 added a commit to DomT4/homebrew-core that referenced this issue Aug 3, 2016

go: rewrite bootstrap steps
* Use more recent versions to handle bootstrapping.

* Drop the unnecessary compile step in the bootstrap versions of Go, which are
already binaries. Ref: golang/go#16579 (comment).

* Cap stable to 10.8-10.11 due to broken build on macOS Sierra/10.12.

* Add explicit versions to the bootstrap to stop them being cached incorrectly
as `go--gobootstrap-64.tar.gz`.

@DomT4 DomT4 referenced this issue Aug 3, 2016

Closed

go: bootstrap rewrite #3581

4 of 4 tasks complete

BrewTestBot added a commit to BrewTestBot/homebrew-core that referenced this issue Aug 3, 2016

go: limit to 10.8 & above.
Upstream don't test or support anything less than 10.8 at this point. There are
a "known" 141 installations below that out of 45k, so doesn't seem to be huge
demand.

Ref: golang/go#16579

BrewTestBot added a commit to BrewTestBot/homebrew-core that referenced this issue Aug 3, 2016

go: rewrite bootstrap steps
* Use more recent versions to handle bootstrapping.

* Drop the unnecessary compile step in the bootstrap versions of Go, which are
already binaries. Ref: golang/go#16579 (comment).

* Cap stable to 10.8-10.11 due to broken build on macOS Sierra/10.12.

* Add explicit versions to the bootstrap to stop them being cached incorrectly
as `go--gobootstrap-64.tar.gz`.

MikeMcQuaid added a commit to Homebrew/homebrew-core that referenced this issue Aug 4, 2016

go: limit to 10.8 & above.
Upstream don't test or support anything less than 10.8 at this point. There are
a "known" 141 installations below that out of 45k, so doesn't seem to be huge
demand.

Ref: golang/go#16579

MikeMcQuaid added a commit to Homebrew/homebrew-core that referenced this issue Aug 4, 2016

go: rewrite bootstrap steps
* Use more recent versions to handle bootstrapping.

* Drop the unnecessary compile step in the bootstrap versions of Go, which are
already binaries. Ref: golang/go#16579 (comment).

* Cap stable to 10.8-10.11 due to broken build on macOS Sierra/10.12.

* Add explicit versions to the bootstrap to stop them being cached incorrectly
as `go--gobootstrap-64.tar.gz`.

Closes #3581.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.