+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.

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

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
.

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.

rc5 is up: https://golang.org/dl/#go1.7rc5

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.

@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

@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?

@quentinmit, see https://git.io/brew-docs and in particular https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/FAQ.md#why-do-you-compile-everything

@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:

    # 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*"]

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.

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?

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.)

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

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.

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.)