If installation is the only problem you are trying to solve, I recommend the -installsuffix flag.

If we support additional GOARCH values for arm, we would need special rules to set the "arm" build tag when GOARCH is "arm5" or whatever. That is possible; I'm just noting it for the record.

Prior to android support landing in the tree splitting arm into three
archectures, arm5, arm6, and arm7, would have meant a 3x increase in the
number of assembly and runtime support files.

However, when android was added an exception was included in cmd/go to
treat android like linux and vice versa to reduce the number of identical
support files.

It may be acceptable (I'm not the decision maker) to define
GOARCH={arm5,arm6,arm7} and use build tags and hints in cmd/go to remove
the GOARM flag.

On Sat, Jan 31, 2015 at 12:35 AM, Ian Lance Taylor <notifications@github.com

wrote:

If installation is the only problem you are trying to solve, I recommend
the -installsuffix flag.

If we support additional GOARCH values for arm, we would need special
rules to set the "arm" build tag when GOARCH is "arm5" or whatever. That is
possible; I'm just noting it for the record.

—
Reply to this email directly or view it on GitHub
#9737 (comment).

@ianlancetaylor uhm... arm8 will come out in Go. It's avaliable in both 32-bit and 64-bit flavors.

Do we still keep GOARCH=arm and tweak GOARM in that case?

BTW, 386 and amd64 are two different GOARCH architectures, although the difference is similar to 32-bit arm7 and 64-bit arm8. We don't have a common GOARCH=intel and GOBITS=32/64 to control that. And that's done for a reason.

@davecheney that is: we have a common runtime for building the arm5/6/7? that makes sense, but what will we do with 64-bits arm8? and with 32-bits?

On Sat, Jan 31, 2015 at 1:47 AM, Vasily Korytov notifications@github.com
wrote:

@ianlancetaylor https://github.com/ianlancetaylor uhm... arm8 will come
out in Go. It's avaliable in both 32-bit and 64-bit flavors.

arm8 is a separate compiler, 7g, in the same way 6g and 8g are distinct.

Do we still keep GOARCH=arm and tweak GOARM in that case?

BTW, 386 and amd64 are two different GOARCH architectures, although the
difference is similar to 32-bit arm7 and 64-bit arm8. We don't have a
common GOARCH=intel and GOBITS=32/64 to control that. And that's done for
a reason.

I agree, GOARM is an aberration, i'd like to get rid of it, rather than
find other commonalities like the one you suggested.

—
Reply to this email directly or view it on GitHub
#9737 (comment).

frankly, I like the idea of keeping a common toolchain for (all possible 32-bit) ARM flavors.

but I also like the idea of separation of GOARCH=arm5/6/7 without separating the actual toolchain. I think, that's possible.

On Sat, Jan 31, 2015 at 1:51 AM, Vasily Korytov notifications@github.com
wrote:

@davecheney https://github.com/davecheney that is: we have a common
runtime for building the arm5/6/7? that makes sense, but what will we do
with 64-bits arm8? and with 32-bits?

To your first question, it's complicate, most of the code for 5,6,7 is
shared, but the choices when to choose different behavior is split between
compile time and runtime.

To your second question, no 64bit arm is a new compiler, 7g, just as 64bit
intel is a different compiler to 32bit intel

—
Reply to this email directly or view it on GitHub
#9737 (comment).

thanks a lot for explaining this, @davecheney

for details about the -installsuffix workaround, see my comment in #9672
#9672 (comment)

(Actually, I think this is a dup of #9672.)

@minux @ianlancetaylor

Uhm, the -installsuffix does not work for me:

> rm -rf $GOPATH/bin/linux_arm/
> ls ~/Go/bin/linux_arm/
ls: cannot access /Users/.../Go/bin/linux_arm/: No such file or directory
> env GOOS=linux GOARCH=arm GOARM=7 go install -installsuffix arm7
> ls $GOPATH/bin/*arm* -d
/Users/.../Go/bin/linux_arm/
> go version
go version go1.3.3 darwin/amd64

Am I doing it wrong?

My binary in that directory is not suffixed either, so I wonder, how it should work.

On Jan 30, 2015 3:22 PM, "Vasily Korytov" notifications@github.com wrote:

Uhm, the -installsuffix does not work for me:

rm -rf ~/Go/bin/linux_arm/
env GOOS=linux GOARCH=arm GOARM=7 go install -installsuffix arm7

GOOS=linux GOARCH=arm GOARM=7 go install -installsuffix arm7 -a -v std

ls $GOPATH/bin/arm -d
/Users/.../Go/bin/linux_arm/
go version
go version go1.3.3 darwin/amd64

Am I doing it wrong?

@minux install std produces some verbose output, but installs nothing here. installing my application with GOOS=linux GOARCH=arm GOARM=7 go install -installsuffix arm7 -a -v gives some verbose output, but still a binary in linux_arm, not arm7:

runtime
errors
sync/atomic
math
unicode/utf8
unicode
sort
sync
container/list
io
syscall
hash
hash/crc32
crypto/subtle
crypto/cipher
bytes
strings
bufio
crypto/hmac
path
time
strconv
math/rand
reflect
crypto
crypto/aes
crypto/md5
crypto/rc4
os
crypto/sha1
crypto/sha256
crypto/sha512
encoding/base64
net/url
encoding/pem
regexp/syntax
path/filepath
net
io/ioutil
fmt
encoding/binary
regexp
crypto/des
compress/flate
math/big
encoding/hex
log
mime
compress/gzip
crypto/elliptic
crypto/rand
crypto/dsa
encoding/asn1
crypto/rsa
net/textproto
github.com/ogier/pflag
crypto/ecdsa
crypto/x509/pkix
crypto/x509
mime/multipart
crypto/tls
net/http
github.com/chillum/httpstress
github.com/chillum/httpstress-go

The compiled binary is $GOPATH/bin/linux_arm/httpstress-go, ignoring the -installsuffix.

That command will only install packages with the given suffix, all binaries
will still be in bin/linux_arm. Do we need to add suffix to that directory
too?

That does not work for me either:

> find $GOPATH/bin -name '*arm7*'
> find $GOPATH/bin -name '*arm*'
/Users/.../Go/bin/linux_arm
> find $GOPATH/bin -name '*httpstress-go*'
/Users/.../Go/bin/linux_arm/httpstress-go

How is it supposed to work? It seems like it's not working for me in giving suffix nor to binaries, nor to directories. What can I discover more?

-installsuffix will only add suffixes to packages under pkg, for example,
pkg/linux_arm_arm5. It won't add suffixes to the directory under bin.
(but the binaries in bin/linux_arm are recompiled with the new GOARM
setting.)

I'm not sure if it should also add the suffix to the bin directory.
@ianlancetaylor?

I think -installsuffix ought to apply to the bin directory as well. I can't think of a reason that it should not.

However, doing that might break the race build. I'm not sure.

Bumping this to Go 1.9 to decide, since we need to figure out other GOARM and ARM5 stuff this cycle.

This just almost bit me again. Fortunately I remembered there might be a bug here and caught myself before trusting GOARM=5 GOOS=linux GOARCH=arm go install. Adding -v showed that GOARM=5 was not part of the buildid and go install thought everything was done and didn't rebuild anything.

We should just put GOARM into the build ID for any compiled package, which will trigger appropriate rebuilds. We shouldn't deprecate GOARM. Same for GO386, GOMIPS(?), and any other env vars that the compiler or linker looks at.

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