build: bootstrapping Go 1.n on macOS Sierra from source #16352
Comments
|
Nevermind. @ianlancetaylor says it works fine on Sierra. You can build Go 1.4 there and time won't work and tests will fail, but it will successfully build Go 1.7. |
|
Good to know. I'm fine with untested 1.4s (the tests take too long to run on my virtual machines so I don't have a choice in those cases =P ); hopefully this won't break something else in the future. |
|
I'm closing this because I believe that it works fine today. |
|
As of Sierra Beta 4, this issue is again relevant. |
|
I think we need to backport this fix in 1.4.4 as soon as possible. |
|
@kirillDanshin, we're going to wait until Sierra is released. It's already changed twice during Sierra betas. |
|
ok @bradfitz ping me here when we'll going to backport the fix, I'll do it. |
|
@kirillDanshin People using a beta version of Sierra and building Go from source should, I hope, be able to apply a patch to their 1.4.3 sources. It doesn't make sense for us to release 1.4.4 now, given that the code in Sierra has changed twice already. |
|
I had a working Go, but the b4 broke it, or I did with something else, so I was (re)installing with brew. Is there a easy(ish) way to build using the 1.4.3 patch with brew, or am I better off just pulling 1.4.3 from git and going from source? |
|
Apple knows. The right people on both sides know the details. It's Go's fault, anyway, not Apple's. |
|
Thanks. And to follow up on the remainder of my comment, I didn't actually need to install from source, and had no reason to have to use brew, so I downloaded the pkg file for 1.7b5 from the main site. It seems to work fine, and based on the git history should contain the fixes for Sierra (for now at least 😁 ) |
|
macOS Sierra GM (Gold Master) came out yesterday. The time system call interface is unchanged from Beta 4. I confirmed that So, should we cherry-pick the time fix back to Go 1.4.4 so there's a source-only way to bootstrap on macOS 10.12+? The cherry picks would be: fad2bbd (the first change, for Sierra beta2) |
|
I suppose I am mildly in favor of doing a 1.4.4 release for better Darwin support going forward. We should also consider #14795 (https://golang.org/cl/21190) and #13114 (https://golang.org/cl/16982). |
|
I fixed #13114 on release-branch.go1.4 already (https://go-review.googlesource.com/c/21598/) |
Updates #16352 Change-Id: I214c87579ef21ced8d0ba94aa170dd7780afec4b Reviewed-on: https://go-review.googlesource.com/32312 Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-on: https://go-review.googlesource.com/32914
|
@broady deployed the docs: https://golang.org/doc/install/source#go14 Closing this. |
@bradfitz -- My reading of the full set of comments here is that if there are other changes needed to keep 1.4 building in the future (even if Apple drops MacOS, etc...) there will be new date-stamped tarballs. Is that correct? I'm touching up the spack packaging for the bootstrap and can either track the tip of the 1.4 release branch or use tarballs. The project has a mild preference for tarballs because one can verify them with digests. |
The last C based Go src tree was the 1.4 series. For a while they were cutting new releases so that people could bootstrap from a C only system. Now they're recommending that you either use the release-1.4 branch or that you use a date-stamped tarball that they'll produce on an as-needed basis. There are several issues that keep 1.4.2 from building on a CentOS 7 system. I've switched to the date based tarball. The cgo bits were also mis-behaving, but they're not needed for the bootstrapping task so I've set an environment variable that disables them. Details [on the install-from-source page](https://golang.org/doc/install/source#go14) and these issues: - golang/go#17545 - golang/go#16352.
Yup. That's the idea. If there are changes needed in the future. |
|
@bradfitz Thanks! |
* Update go-bootstrap package The last C based Go src tree was the 1.4 series. For a while they were cutting new releases so that people could bootstrap from a C only system. Now they're recommending that you either use the release-1.4 branch or that you use a date-stamped tarball that they'll produce on an as-needed basis. There are several issues that keep 1.4.2 from building on a CentOS 7 system. I've switched to the date based tarball. The cgo bits were also mis-behaving, but they're not needed for the bootstrapping task so I've set an environment variable that disables them. Details [on the install-from-source page](https://golang.org/doc/install/source#go14) and these issues: - golang/go#17545 - golang/go#16352. * Update go package Switched from pulling from the git repository to using the source tarballs and added digest values. Added support for 1.7.3, continued supporting 1.6.2, including patches for a couple of problems (details in [17545](golang/go#17545) and [17986](golang/go#17986). Dropped support for 1.5.4 and 1.4.2 because they no longer pass their tests and the patches above to not apply.
* Update go-bootstrap package The last C based Go src tree was the 1.4 series. For a while they were cutting new releases so that people could bootstrap from a C only system. Now they're recommending that you either use the release-1.4 branch or that you use a date-stamped tarball that they'll produce on an as-needed basis. There are several issues that keep 1.4.2 from building on a CentOS 7 system. I've switched to the date based tarball. The cgo bits were also mis-behaving, but they're not needed for the bootstrapping task so I've set an environment variable that disables them. Details [on the install-from-source page](https://golang.org/doc/install/source#go14) and these issues: - golang/go#17545 - golang/go#16352. * Update go package Switched from pulling from the git repository to using the source tarballs and added digest values. Added support for 1.7.3, continued supporting 1.6.2, including patches for a couple of problems (details in [17545](golang/go#17545) and [17986](golang/go#17986). Dropped support for 1.5.4 and 1.4.2 because they no longer pass their tests and the patches above to not apply.
These patches are for two issues: * Enabling Go to build on Alpine by disabling PIC per: golang/go#6940 https://github.com/docker-library/golang/blob/master/1.7/alpine/no-pic.patch * Fixing Go 1.4 bug appearing on macOS 10.12.1 per: golang/go#16352 (comment)
These patches are for two issues: * Enabling Go to build on Alpine by disabling PIC per: golang/go#6940 https://github.com/docker-library/golang/blob/master/1.7/alpine/no-pic.patch * Fixing Go 1.4 bug appearing on macOS 10.12.1 per: golang/go#16352 (comment)
…strap it Otherwise it started to fail this way: [2017-02-22 11:49:22,982] INFO --- FAIL: TestLoadFixed (0.00s) [2017-02-22 11:49:22,982] INFO time_test.go:929: Now().In(loc).Zone() = "-01", -3600, want "GMT+1", -3600 [2017-02-22 11:49:22,983] INFO FAIL [2017-02-22 11:49:22,983] INFO FAIL time 2.380s See golang/go#16352 (comment) and around for details.
|
download https://storage.googleapis.com/golang/go1.4-bootstrap-20161024.tar.gz @bradfitz Thanks! |
Of particular interest are the updates to `./go install languages go` whereby the Go source repo is primed with the `GOROOT_BOOTSTRAP` version in `_prepare_go_repo_for_bootstrap`. This is necessary due to the macOS Sierra issues described in golang/go#16352. The fix is only in the `release-branch.go1.4` branch not a tag, which causes `gvm` not to find it without this priming step.
|
Still need a "real" binary release of 1.4.4, for some packaging system, some fast bootstraping purpose (without having to build go 1.4.4), or use gonative+gox tools on macos, and so on. I dont know which problem does it generate to make a binary release instead of just source release ? Please just release a binary go1.4.4 ! |
|
You can use 1.9.2 for that purpose.
…On Nov 8, 2017 7:38 PM, "StudioEtrange" ***@***.***> wrote:
Still need a "real" binary release of 1.4.4, for some packaging system,
some fast boostraping purpose (without having to build go 1.4.4) and so on.
I dont know which problem does it generate to make binary release instead
of just source release ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16352 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABhlvlPzDBhOwgAw5OkexqckNNuuwnNks5s0nO-gaJpZM4JLtk3>
.
|
|
No, I cannot use 1.9.2 in some use case, for example for gonative+gox. So, what is the exact problem of releasing 1.4.4 binary ? |
|
Can you help me understand why you need a 1.4.x binary release? You can use any recent version of Go to bootstrap an environment to compile from source. You only need the 1.4.x source to bootstrap if you want to build entirely from source. I thought there was an explanation of this somewhere, but I can't find it. |
|
Ok
Some go application use this setup to cross compile go application. And for now, gonative needs go1.4 to work. Then it download binaries and prepare cross compiling toolchain, then we use gox to cross compile. So, getting in first place go1.4.4 (so with patches for macos included) to be built before cross compilation take a while in case of bootstraping chain. That's a use case of having 1.4.4 binary available |
|
Why does gonative require go1.4? I find that hard to believe. This sounds like an issue with gonative. /cc @inconshreveable |
|
Dont know yet.
|
|
@StudioEtrange gonative is very, very old and almost certainly no longer necessary or the right way to do whatever it is that you're trying to do. i no longer use it and you should consider it a deprecated tool. any issue with it also belongs on that repository and not here |
|
Please don't comment on long-closed issues. We don't track them. |
and others
@andlabs pointed out in #16272 (comment) that as of macOS Sierra, we'll have no way to bootstrap Go 1.N from source.
Maybe we need to backport @ianlancetaylor's time fix to Go 1.4?
The text was updated successfully, but these errors were encountered: