Naming convention for aarch64 binary distribution is unique

[vielmetti]

The current release distributes a binary for aarch64 (arm64) named

https://github.com/google/protobuf/releases/download/v3.5.1/protoc-3.5.1-linux-aarch_64.zip

The use of the string 'aarch_64' is unusual, since uname -m on a real aarch64 machine returns this

root@ed-2a-bcc-llvm:~# uname -m
aarch64

In particular this affects me at linkerd at

linkerd/linkerd#1695

where the line in their file at

https://github.com/linkerd/linkerd/blob/cbef41b40ff5de41f9fa41615f7f1b363eae2ead/protoc#L14

that bootstraps protoc will not pick up the right image without some architecture-special tweaking that I want to avoid.

[jtattermusch]

just FTR, the aarch_64 suffix is not unheard of. I think it comes from the conventions use by java build tools (e.g. see here: https://github.com/netty/netty-tcnative/pull/591/files)

I think originally the weird naming stems from the fact that maven artifacts (see https://mvnrepository.com/artifact/com.google.protobuf/protoc/3.17.3) are used as part of the protobuf's release process.
As a side-effect the files published with each release end up with the unusual aarch_64 suffix.

(note that I'm not arguing the the current way of naming the binaries is correct, I'm just explaining the background of the problem).

[HenriBeck]

@jtattermusch, would it still be possible to add the aarch64 as a distribution, so people don't need to do these mappings?

Especially with ARM gaining a lot of attention with the M1 Macs, this would be very beneficial.

[ejona86]

The Java release in Maven Central needs aarch_64. It is used by Maven and Gradle plugins and follows the cross-architecture consistent naming used by os-maven-plugin.

But that has no impact on the names used for the downloads on the release page. I'd agree that mirroring uname -m in that situation would be advantageous. I think right now it is just a copy of the approach used for Java.

Note that last I saw there isn't actually any aarch64 protoc binary available at the moment. It is actually just an x86_64 binary renamed to help tooling. See #8557

[deannagarcia]

As stated, this is to stay consistent with the hard requirements for Maven Central. So unfortunately we won't be able to change the name.

[deitch]

I think the OP was suggesting that this be added, even just as a link. Without this, every download needs to go through an odd if [ "$(uname -m)" = "aarch64" ]; then targetarch="arch_64"; fi (repeat for others archs.

Is there a good reason not to have links for both aarch64 and aarch_64 both point to the same release artifacts? Same question for riscv64, etc.?