build: distribute linux/arm64 binaries for Go releases

[benshi001]

Current go 1.8 only contain an armv7l-linux package.

However linaro is also a popular 32/64-bit arm-linux platform, an aarch64 package in future go releases might be useful.

http://www.linaro.org/

[davecheney]

Do we really need to do this? The only reason we package linux/arm (32bit) is it takes hours to compile natively. Most arm64 systems can knock this over in 10 minutes. Also, is this a problem that linaro, as a distro maintainer, should handle?

…

On Tue, Feb 14, 2017 at 6:08 PM, Ben Shi ***@***.***> wrote: Current go 1.8 only contain an armv7l-linux package. However linaro is also a popular 32/64-bit arm-linux platform, an aarch64 package in future go releases might be useful. http://www.linaro.com/ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19082>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA-u2Mi8WKGEA2ngCGRy7JX-Zx6Vcks5rcVLXgaJpZM4MAIjx> .

[benshi001]

An generic aarch64-Linux go pre-built package might not benefit a go developer, but it might benefit a go user who use go to build web apps. He might want only a go package than gcc and git which are needed to build go from source.

[vielmetti]

An officially supported 64-bit ARM version of Go would help a whole bunch of downstream projects that depend on Go, including especially Docker, and then anyone building multi-architecture projects that depend on Go in Docker containers. As it stands now the container process would have to bootstrap Go from source which adds complexity at the minimum and bloat.

There's a whole set of tooling and packaging for other platforms that depends on plopping in a supported binary as part of an automated build system.

[vielmetti]

To give you an idea of some of the hoops people are going through to bootstrap Go right now, I give you https://github.com/hypriot/golang-armbuilds - this should all be unnecessary when there's an official build.

[zsmithnyc]

agreed, Go is a popular multi-arch capable supporting tool for many projects. Including a binary would be very convenient and also support more testing and CI that should be using an official build.

[benshi001]

The linux/arm64 can be attributed to "Other Ports". Something like
go1.9.linux-arm64.tar.gz

There are
go1.8.1.linux-ppc64le.tar.gz Archive Linux ppc64le 73MB b7b47572a2676449716865a66901090c057f6f1d8dfb1e19528fcd0372e5ce74
go1.8.1.linux-s390x.tar.gz Archive Linux s390x 72MB 0a59f4034a27fc51431989da520fd244d5261f364888134cab737e5bc2158cb2
in "Other Ports"

[andrewhsu]

Having official google builds of golang for arm64 would be fantastically useful for users that just want to simply compile stuff on arm64 without having to do the golang bootstrap procedure.

[bradfitz]

Per https://golang.org/wiki/NoMeToo, please vote with the emoji thumbs up at the top.

[tianon]

As a datapoint against the target system build times, there are official binary releases for s390x and ppc64le, both of which are mainframe platforms and thus usually can also build Go fairly fast (but having official binary releases is still really useful).

[glevand]

Just FYI, you can use gimme: https://github.com/travis-ci/gimme. It will build from source if it can't find a binary release.

[alexellis]

An official build of Golang for ARMv8 will save a lot of hassle for Docker images and build pipelines. Automation is everything and this lack of support makes working with 64-bit ARM harder.

RE: the argument of only taking 10 mins to build Go - I haven't tried this on one of the lower-powered SoCs, but certainly for CI - 10 min is a huge penalty over the time it takes to DL/un-tar.

[zsmithnyc]

@davecheney just as a point of clarification, Linaro isn't a Linux distribution. Rather the organization simply works on upstreaming open source arm software eg kernel, etc.

However, I think that Linaro and others in the arm ecosystem (eg huawei, cavium, Qualcomm, etc) would be willing to help maintain a native aarch64 build of GoLang.

Packet and ARM are already donating CI infrastructure for both 32 and 64 bit arm builds. I suspect Scaleway would also be supportive.

In the end, Packet and scale way each have thousands of customers using our armv8 infrastructures. A large percentage of these users have expressed a desire to have a pre built official binary. The main use case seems to be for using golang dependent software, eg Docker, k8s, cockroach etc

[glevand]

We need at least one arm64 go binary release to use as the bootstrap compiler to build other go versions. As of now, we cannot build any version of go on an arm64 machine since arm64 support was added in go1.5, and go1.5 needs a go bootstrap compiler to build itself.

[davecheney]

Can you build the bootstrap compiler on a other machine?

…

On Tue, 9 May 2017, 09:54 Geoff Levand ***@***.***> wrote: @davecheney <https://github.com/davecheney> We need at least one arm64 go binary release to use as the bootstrap compiler to build other go versions. As of now, we cannot build any version of go on an arm64 machine since arm64 support was added in go1.5, and go1.5 needs a go bootstrap compiler to build itself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19082 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA6H5flPwjUUeZNncSEzFvplxJTbKks5r36shgaJpZM4MAIjx> .

[vielmetti]

@davecheney when you build the bootstrap compiler on another machine (according to your directions) you get this project by @hypriot and Dieter Reuter. https://github.com/hypriot/golang-armbuilds

[glevand]

@davecheney I don't think it reasonable to require a user on an arm64 machine to have another machine to simply build a bootstrap program.

[alexellis]

Is there any resistance to the proposal or was this additional information just for technical reference? I think this would benefit the community - well beyond the scope of Linaro.

[bradfitz]

@alexellis, yeah, this is mostly a tracking bug. We're almost certainly going to do this, especially now that we have an "Other Ports" section on the download page, and we already have relatively infrequently used ports like s390x there.

[bradfitz]

@broady, I'm running using pending CL 45913:

$ release -rev=952ecbe0a27aadd184ca3e2c342beb464d6b1653 -skip_tests -target=linux-arm64 -tools=6d30ceaab7ab5caffba4974a61e36d34268756ec -version=go1.9beta1 -watch
2017/06/15 19:45:42 linux-arm64: Start.
2017/06/15 19:45:42 linux-arm64: Creating buildlet.
2017/06/15 19:45:43 linux-arm64: Pushing source to buildlet.
....

[bradfitz]

Okay, it's uploaded now:

https://golang.org/dl/#unstable

The "Arch" column says "arm64" now. Maybe it should say something else. It looks out of place formatting-wise. ARMv8? ARMv8-A? AArch64? ARM has the most lovely names. ARMv8 matches the existing ARMv6 look-wise.

In any case, please test out the binary and report any problems.

If we don't hear happy reports, we won't ship it for the final release.

[nathangoulding]

@bradfitz My vote would be for arm64, and probably rename ARMv6 to arm32. Since there are a few 64-bit architecture now, perhaps amd64 and i386 instead of 64/32-bit.

[alexellis]

There are varying opinions on naming for ARM - ARM themselves communicating with the Docker/Moby project asked for -

• arm32v6
• arm32v7
• arm64v8

etc. This has been reflected in the Docker manifest definitions and the prefixes for the naming of ARM-based container images.

aarch64 / arm64 / armv8 amongst others are the most popular I've seen elsewhere. Every project seems to do something different - which makes maintaining ports harder.

[bradfitz]

We'll go with ARMv8 if anything. We're not repainting the rest of the house.

[bradfitz]

@nathangoulding, for anybody actually confused what "64-bit" or "32-bit" means, they can read the filename substring that says "amd64" or "386".

[nathangoulding]

@bradfitz More so for accuracy/consistency, especially as golang makes its way into predominantly ARM ecosystems. Fair enough though, and ARMv8 is a fine choice.

[benshi001]

I suggest aarch64. ARMv8 implies arm32 instruction set ver 8, and aarch64 implies the 64 bit mode instruction set, as a convention.

Please refer to linaro tool chain's naming.

https://www.linaro.org/downloads/

[tianon]

If we don't hear happy reports, we won't ship it for the final release.

Happy to report that it's working pretty well here! 😇 👍 😀

(It successfully builds binaries as expected, and the resulting binaries run properly. ❤️)

Thanks for your work on this! 💯

[emaste]

On a related note, I see there are FreeBSD go binaries for 32- and 64-bit x86, but not for 32- or 64-bit arm. Should I create a "build: distribute freebsd/arm64 binaries for Go releases" issue?

[bradfitz]

No, because we don't have a freebsd/arm64 port.

[emaste]

Ok, so first I'll open an issue for the FreeBSD/arm64 port - it will be useful to at least track requirements for bootstrapping.

[gopherbot]

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

[vielmetti]

I take it that's a "yes", if so, thanks.

[rhenwood-arm]

If we don't hear happy reports, we won't ship it for the final release.

My colleague, @naveena2016, shared test results with me. She used the AArch64 1.9 beta2 binary. Her effort included four different workloads that completed without issue. Performance could be characterized as 'similar to 1.8'.

Thanks for preparing this release!

[eanger]

I've run some experiments to check out the behavior of the AArch64 1.9b2 binary, looking at the performance of the workloads in the Computer Language Benchmarks Game. All the benchmarks worked as expected. Here's a figure showing speedup of 1.9b2 over 1.6 for each of the benchmarks:

Thanks!

[alexellis]

Nice @EagneR - out of interest which machine did you run these on?

[eanger]

It was run on an A57 platform restricted to using a single core.