-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
"Installing Go from Source" - cannot build cmd/dist of "go1.12.7" using bootstrap go from "release-branch.go1.4" #33402
Comments
Hi, the installation instructions says:
Which basically boils down to:
But you choose the second, more difficult path, mentioned later:
This second path requires you to
My question is: why did you choose the second, more difficult, path? Why are you trying to build the bootstrap 1.4 compiler from source, even if this is not strictly necessary, since you can use any released Go toolchain to bootstrap? Is it because the documentation is not clear enough in explaining that those are two completely different paths? |
I think the problem is here:
I think the bootstrap needs its own untouched folder (e.g. for src and std lib packages) so checking out go1.12 into the folder of the bootstrap will confuse the bootstrap go compiler. At least I never tried to mix these when bootstrapping. So the missing steps after building go1.4 are:
This seems implicit in the installation instructions after the bootstrap:
New directory+new clone of the source and checkout of go1.12.7. |
I'm tempted to flippantly reply "because it was there" ;) ...or perhaps: "please don't blame me, I was raised in a Gentoo household" </end joking> Your time in reading my issue merits my respect, and I wish to give you that respect. I certainly don't want anyone reading this ticket to think that Go is tricky to install! Thank you for putting that notion to rest, and making sure to point out that potential Go users have many painless ways to get started. That's a very important point to make. I did see that there are many options. My choosing the "difficult path" (really not so bad now that I got unstuck) was deliberate. My motives do not affect the precise steps and outputs that I reported, so I omit my motives from the ticket :) Potential new contributors who don't shy away from the difficult things could be useful to an open source project! Counterpoint: working with people who relentlessly and pointlessly do things the difficult way all the time is certainly exhausting and frustrating. If that is the bigger issue faced by any group, then that group has my full sympathy. |
Yesssssssss. Your advice did the trick. Many thanks! Clearly, I made some wrong assumptions. I assumed that what ended up in "pkg" and "bin" was essentially independent from "src" after the bootstrap go had been compiled. Thank you for clearing this up.
Implicit, I agree. But could be made more explicit. There were several options for obtaining the compiler binaries, and not all options involved Therefore, when I came to the instruction to "clone the repository and check out the latest release tag" (which appears several sections below the compiler binaries section), I guessed (incorrectly) that it might be reasonable to use an earlier clone in the (uncommon) case where I had already done I very much appreciate your careful, well-laid-out, thoroughly explained reply! Do you think a patch (from me, based on this issue) would be welcome to the HTML doc? If it is welcome, I will happily attempt the work. If the community would rather not put energy into this little-used bootstrap tactic, then I can understand that, too. |
yes. I was meaning to suggest (pending on the outcome whether that was the issue) that we should make explicit that the bootstrap and the to be build version of go can not share the same base directory. Im not sure what the right wording will be but that can be discussed on the CL with other Go maintainers more knowledgable about that part of the documentation reviewing. |
Thanks, @martisch ! I will close this issue and work on a CL. |
Change https://golang.org/cl/188900 mentions this issue: |
…t clone" Prior doc implied that "git clone" was one way to obtain a go1.4 bootstrap toochain, but it did not state this outright. Further, the doc did not make it explicit in the "Fetch the repository" section that one must necessarily "git clone" a second time in the (presumed-to-be-uncommon) case where "git clone" had already been perfomed in the "compiler binaries" section. Updates #33402 Change-Id: Id70a6587b6ee09aca13559d63868b75cb07dff1e Reviewed-on: https://go-review.googlesource.com/c/go/+/188900 Reviewed-by: Ian Lance Taylor <iant@golang.org>
My issue is very similar to issue #20347 although the supposed "import cycle" that gets reported is different.
(I say "supposed" import cycle because when I inspect the code in question I do not see any import cycle, so I suspect potentially a bug in the bootstrapped "go" binary, possibly due to some incorrect way that I am building it.)
I understand that #20347 was closed under suspicion that the user was not properly following directions at https://golang.org/doc/install/source
Perhaps I am also not following the directions, but I believe I can provide a more complete bug report, and I will be attentive to any follow-up requests for more details. (I also believe that I am correctly following the directions, although the webpage seems a little vague in the section about building "go compiler binaries" for oneself.)
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes, if the git tag "go1.12.7" counts as the latest version. Otherwise, no. I will happily retry my steps with another git tag if requested.
What operating system and processor architecture are you using (
go env
)?What did you do?
I have carefully reproduced the above steps several times, so at least I know that what I am doing should be completely replicable by another person.
Can anyone spot something clearly wrong in my steps shown above?
If so, then this is just a matter of making the instructions clearer at https://golang.org/doc/install/source
If you cannot spot an error, then please try those steps locally. If the same steps succeed for someone else, then something might be wrong with my Ubuntu machine and/or its compiler toolchain.
What did you expect to see?
I expected to be able to continue following the instructions at https://golang.org/doc/install/source
Specifically, after the "make.bash" step I planned to:
$ cd src
$ ./all.bash
At which point, if all goes well, it will finish by printing output like:
ALL TESTS PASSED
(per https://golang.org/doc/install/source)
What did you see instead?
I cannot make sense of the "import cycle" that is reported, because I do not see that "internal/cpu" actually imports "runtime", except in tests. But if I delete the tests, I still see this same report of a cycle.
(am I correct to look for imports using
grep -r runtime internal/cpu/
?)The crux of the mystery:
What could cause a "go" binary to report such a cycle when that "go" binary is run against the "go1.12.7" tag of the git repo like so:
/opt/repos/go_001/go/bin/go build -o cmd/dist/dist ./cmd/dist
And how can I recompile my "go" binary so that it succeeds at building "cmd/dist" from the "go1.12.7" tag?
The text was updated successfully, but these errors were encountered: