Support aarch64 builds

[8W9aG]

If you have a build matrix for a bunch of different architectures and rely on the following to copy in the correct binaries:

sudo curl -o /usr/local/bin/cog -L "https://github.com/replicate/cog/releases/latest/download/cog_$(uname -s)_$(uname -m)"
sudo chmod +x /usr/local/bin/cog

You will notice that aarch64 isn't supported here. Could ease friction if we change the release pipeline to support this arch.

[nevillelyh]

Stumbled across this and I'm not sure it's an issue though. The root cause is Intel vs ARM being handled differently on Linux, macOS and GOARCH.

• M1 Mac: uname -m: arm64
• Linux container on M1 Mac: docker run -it --rm alpine uname -m: aarch64
• Both Mac & Linux use x86_64 for Intel chips
• Go uses amd64 & arm64

Usually it's solved in scripts with something like:

case "$(uname -m)" in
    aarch64) arch=arm64 ;;
    x86_64) arch=amd64 ;;
esac

[8W9aG]

Stumbled across this and I'm not sure it's an issue though. The root cause is Intel vs ARM being handled differently on Linux, macOS and GOARCH.

• M1 Mac: uname -m: arm64
• Linux container on M1 Mac: docker run -it --rm alpine uname -m: aarch64
• Both Mac & Linux use x86_64 for Intel chips
• Go uses amd64 & arm64

Usually it's solved in scripts with something like:

case "$(uname -m)" in
    aarch64) arch=arm64 ;;
    x86_64) arch=amd64 ;;
esac

Yeh I agree that its generally easy to script your way out of this (and in fact maybe we should explicitly do this in the install script), however a bit of an issue could arise where this assumption was made in deeper layers where a build script just executes the uname -m without consideration. This too can be fixed however perhaps it might be simpler to centralise the fix by offering the binary (even if it is identical to arm64) since it should just be a copy of a release artifact. Could mean less work for the customer (even if small).