-
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
build: 386 build with GO386=387 no longer runs on older CPUs #8152
Labels
Milestone
Comments
for GO386=387 builds, you will have to rebuild Go by yourself, otherwise it won't be effective for standard packages. please refer to http://golang.org/doc/install/source for details, be sure to export GO386=387 before running all.bash or make.bash. Status changed to WaitingForReply. |
Hmm. That sounds like it could be the cause. But I also read that GO386=387 is the default when cross compiling, i.e. this should already have been the case when I built Go for crosscompilation on darwin/amd64? I admin that "I read" is from some maybe not authoritative go-nuts post so it may be a misunderstanding... |
yeah, there is a problem. if cross compiling on PC, cmd/dist will detect the host cpu's sse2 capability and set GO386 based on that. But, there is another problem if we change this behavior: if an amd64 user compiles Go for GOARCH=386 without setting GO386 and GOHOSTARCH, then the new toolchain will only use 387 FP instructions, not sse2 as it is probably expected by the user. The other option is to modify the doc/install-source.html to say this: $GO386 (for 386 only, default is auto-detected if build on 386 or amd64, 387 if not). Which one do yo prefer? Owner changed to @minux. Status changed to Accepted. |
I have no problem with the default being to use SSE2 if that is better for most people, as long as I can recompile it. If I understand you correctly, the situation at the moment is that as long as I'm compiling go on any kind of x86 CPU, I'm "native" and it will be autodetected to whatever my CPU can handle? Whereas I assumed "native" meant I was actually on a 32 bit CPU. That said, do people really expect those instructions in 32 bit builds? I'm publishing binary builds for a project of mine, it apparently breaks with SIGILL on a bunch of old or small (i.e. NAS) hardware out there. Most/all other binaries compiled for 32 bit x86 seem to work fine, i.e. a regular Ubuntu and so on? I'll recompile everything with GO387=386 and see what happens. |
Personally, when I'm building for 32 bit I'm not exactly targeting the high performance systems out there and performance isn't the main driver - compatibility is. So the capabilities detected on my (quite modern) build box is a poor indicator of the capabilities of the systems the 32 bit binaries will actually run on. |
Re #6, yes, your understanding is right. I believe we should do something for this issue: either modify the cmd/dist behavior to match the docs if we interpret "building natively" as building with GOARCH==GOHOSTARCH, or change the docs to say GO386 will be auto-detected if building on x86 (both 386 and amd64). Now I'm leaning towards the docs change for 1.3. Ian, what's your opinion? It's a small change either way. |
CL https://golang.org/cl/102150046 mentions this issue. |
This issue was closed by revision ae1b5c7. Status changed to Fixed. |
CL https://golang.org/cl/105830044 mentions this issue. |
minux
added a commit
that referenced
this issue
May 11, 2015
…ill be auto-detected when building on both 386 and amd64. ««« CL 102150046 / ccf7893cc2f0 doc/install-source.html: document that GO386 will be auto-detected when building on both 386 and amd64. Fixes #8152. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/102150046 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/105830044
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: