Image for aarch64 Windows toolchain on aarch64

[NickDarvey]

I've been using ghcr.io/taiki-e/rust-cross-toolchain:x86_64-pc-windows-gnu-dev-amd64 as the image for a dev container. Now I've got an aarch64 (Windows) host and I want to build for aarch64 Windows.

I see in the readme that 'Windows (LLVM MinGW)' has the host 'x86_64/aarch64 Linux (glibc 2.17+)' and supports the target 'aarch64-pc-windows-gnullvm'. I think this is what I want, however, I'm not sure which image this corresponds to.

➜ X:\  docker pull ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-arm64

Error response from daemon: failed to resolve reference "ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-arm64": ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-arm64: not found

➜ X:\  ✗ docker pull ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-aarch64

Error response from daemon: failed to resolve reference "ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-aarch64": ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-aarch64: not found

Related to #3.

[taiki-e]

Our containers are multi-arch containers, so remove the host architecture suffix (-amd64/-arm64v8) and then the appropriate image for the host will be automatically pulled if supported.

the readme that 'Windows (LLVM MinGW)' has the host 'x86_64/aarch64 Linux (glibc 2.17+)'

This was actually mistake in readme, at the time you submitted this issue aarch64-pc-windows-gnullvm was not supported for aarch64 host, but this has already been fixed in the latest image. (f1e6e3e8c59c4a021e98f89e6c64d36098d215af)

In any case, note that the support for aarch64 hosts is experimental overall at this time (only building images since emulation is very slow), because it has not been tested by CI. (The situation here regarding aarch64 hosts will improve as github's support for aarch64 runners improves.)

[NickDarvey]

@taiki-e, that worked perfectly. Thanks for fixing that so swiftly.

One follow-up: am I right in thinking I need to change images based on the target? For example, for targeting x86_64 I must use ghcr.io/taiki-e/rust-cross-toolchain:x86_64-pc-windows-gnullvm-dev, but for targeting aarch64 I must use ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev.

For the dev container use case, I'd like it so that a developer who clones the repo on their x86_64 machine targets x86_64, but a developer cloning on their aarch64 machine targets aarch64. One option is for me to just have multiple dev containers and make the developer pick which one to open, but can you think of any other options? For example, would some kind of superset image be possible?

[taiki-e]

For example, would some kind of superset image be possible?

It just builds images with different tags depending on the architecture of the host, right?

# Dockerfile
ARG ARCH
FROM ghcr.io/taiki-e/rust-cross-toolchain:"${ARCH}"-pc-windows-gnullvm-dev

# build_docker.sh
case "$(uname -m)" in
    x86_64 | x86-64 | x64 | amd64) arch=x86_64 ;;
    aarch64 | arm64) arch=aarch64 ;;
    *) echo "unsupported host architecture '$(uname -m)'" && exit 1 ;;
esac
docker build ... --build-arg "ARCH=${arch}"

It may actually be possible to do the same thing using docker manifest without building the image. (This is the way we build multi-arch images.)

tag=...
docker manifest create --amend "${tag}" ghcr.io/taiki-e/rust-cross-toolchain:x86_64-pc-windows-gnullvm-dev-amd64 ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-arm64v8
docker manifest annotate --os linux --arch amd64 "${tag}" ghcr.io/taiki-e/rust-cross-toolchain:x86_64-pc-windows-gnullvm-dev-amd64
docker manifest annotate --os linux --arch arm64 --variant v8 "${tag}" ghcr.io/taiki-e/rust-cross-toolchain:aarch64-pc-windows-gnullvm-dev-arm64v8
# docker manifest push --purge "${tag}"

I don't know if devcontainer itself supports architecture-dependent image selection. Related discussion: https://github.com/microsoft/vscode-remote-release/issues/2067