doc: document that GOARM applies to cmd/gc as well

[rasky]

Hello, I have a program, written for a specific Linux-ARM5 board, whose cpuinfo is:

Processor   : ARM926EJ-S rev 5 (v5l)
BogoMIPS    : 56.52
Features    : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part    : 0x926
CPU revision    : 5

Hardware    : Bluegiga APX4 Development Kit
Revision    : 9050003
Serial      : 000000004d9ec28b

The program appears to work with Go 1.2, while it segfaults at startup (illegal instruction) with 1.3 and 1.4. After closer testing, it appears related to whether the Go compiler is compiled with GOARM=5 or not, even if we always pass GOARM=5 at go build time. In fact, documentation is a little fuzzy on details; I always assumed that whatever you pass during make.bash is just a default, that can be overriden during go build.

This is the result matrix of my tests:

• Go 1.2: GOARM=5 ./make.bash followed by GOARM=5 go build: SUCCESS
• Go 1.2: ./make.bash followed by GOARM=5 go build: SUCCESS
• Go 1.3+: GOARM=5 ./make.bash followed by GOARM=5 go build: SUCCESS
• Go 1.3+: ./make.bash followed by GOARM=5 go build: SIGILL

I ran git bisect and found out that this change in behavior was introduced by the commit 4230044. So before that commit, I can avoid using GOARM=5 while building the Go compiler, and produce working binaries; after that commit, I need to pass GOARM=5 while building the Go compiler, otherwise the binaries don't work.

Notice that in all my testing I never saw the nice error message introduced in 212ce41. Maybe the fact that this message is not shown is part of this bug, or maybe it's just a different orthogonal bug, but I thought it was worth mentioning.

[minux]

Starting with Go 1.3, GOARM is no longer a link time setting, so you have
to also set it when building the standard packages (I.e. during make.bash)

We do need to document this better.

[rasky]

Yes, I think a documentation update is required. Some additional comments:

• Can I now have a Go compiler installation that can produce both ARM5, ARM6 and ARM7 binaries? That is, does a GOARM=5 make.bash compilation overwrite a GOARM=6 make.bash compilation, or not?
• Shouldn't the error in 212ce41 appear if I run a ARM6 binary on ARM5, instead of segfaulting? Or was that error removed later on, and the expected behavior is now a segfault (like it was before)?
• I see many build scripts and blog posts that assume that the matrix created iterating on GOOS and GOARCH is enough to create all binary versions of the Go compiler; for instance, the Homebrew formula assumes that GOOS=linux GOARCH=arm� is enough to create a fully-functional ARM cross-compiler, while that's not true anymore.

[minux]

Hint to your first question: see docs for go install -installsuffix option.
You just need to build three copies of standard packages.

Similar to GOARM, GO386 affects 386 code generation.

Just building for all GOOS/GOARCH combinations is not sufficient for a
toolchain to be able to produce binaries for all supported platforms.

[rasky]

Sorry if I'm being dense, but I can't see how to produce a single toolchain installed into a single prefix that can compile both ARM5 and ARM6 binaries (just like it can also compile linux-x64 and darwin-386). If I run GOARM=5 ./make.bash it compiles the standard library into pkg/linux_arm, which is then overwritten by GOARM=6 ./make.bash.

Am I supposed to just build the standard library with another script, and then manually use -installsuffix? And if so, how do I select the right standard library while compiling an application?

[minux]

I meant after running GOARCH=arm make.bash --no-clean:

GOARM=5 GOARCH=arm go install -installsuffix arm5 std
GOARM=6 GOARCH=arm go install -installsuffix arm6 std
GOARM=7 GOARCH=arm go install -installsuffix arm7 std

When you want to build something, use the appropriate -installsuffix as well.
GOARM=6 GOARCH=arm go build -installsuffix arm6 somepkg

Because GOARM setting affects the compiler, there is no way to avoid extra
copies of the compiled packages.

[rasky]

OK many thanks for the clarification.

My comment is that it's really an unfortunate choice, and breaks the orthogonality of the multilib system you already have in place. GCC doesn't have this problem for instance. I am not qualified to comment on what could be a possible improvement to this situation, but you are surely making the life harder to embedded developers.

[gopherbot]

CL https://golang.org/cl/12620 mentions this issue.