Only use prebuilt musl libc binary with x86_64 arch

[danifv]

Fixes #30170

As described in #30170, bootstrap-vcpkg.sh currently incorrectly downloads x86_64 binaries for arm hosts, if the host is running alpine linux, regardless of the host architecture.
This PR fixes this issue, by checking the platform architecture along /etc/alpine-release. If the architecture is not x86_64, it will default to compiling the source, as it already happens on other distributions, e.g. ubuntu.

[jimwang118]

Thank you for mentioning this PR, our ci does not have a corresponding machine to test this change, so please make sure that the local test is ok.

[dg0yt]

I wonder if the download block wouldn't be better served by a case pattern as commonly found in configure scripts:

case "${UNAME},${ARCH},${vcpkgUseMuslC}" in
Darwin,*)
...
Linux,x86_64,ON)
...
Linux,x86_64,*)
...
*)
...
esac

This could be easily extended to support arm, bsd or similar.

[dg0yt]

This change also removes vcpkgUseSystem="ON" from non-x86_64. This doesn't seem right to me.

[danifv]

When using current vcpkg, I get the following message if I try bootstrapping on an alpine host, that lacks the required packages:

./vcpkg/bootstrap-vcpkg.sh -disableMetrics
On Alpine:
  apk add build-base cmake ninja zip unzip curl git
  (and export VCPKG_FORCE_SYSTEM_BINARIES=1)

If I install the required packages, without setting VCPKG_FORCE_SYSTEM_BINARIES to 1, and then proceed to installing a package, then I get a note saying, that a suitable version of cmake was not found, which is followed by a download of Kitware/CMake.
However, if I set VCPKG_FORCE_SYSTEM_BINARIES=1, then my system installation of CMake is used, so vcpkgUseSystem by itself doesn't seem to have an effect.

If I bootstrap on aarch64 without VCPKG_FORCE_SYSTEM_BINARIES, an x64_86 distribution is downloaded, so not only is vcpkgUseSystem without effect, but an incompatible binary is downloaded.

What is the relation between VCPKG_FORCE_SYSTEM_BINARIES and vcpkgUseSystem? What is the expected behavoiur?

[jimwang118]

@dg0yt Please help to make sure this modification is correct.

[jimwang118]

@danifv Please make sure that this modification only works on x64 and has no effect on other platforms. If you can confirm that the revision is correct, I will submit the application for integration.

[danifv]

@danifv Please make sure that this modification only works on x64 and has no effect on other platforms. If you can confirm that the revision is correct, I will submit the application for integration.

I've changed the code, so that vcpkgUseSystem="ON" remains set on alpine for all archs.

Otherwise I can confirm, that behaviour on x64 remains unchanged, and that on other archs a correct binary is compiled instead of an incorrect one being downloaded.

[BillyONeal]

Can you help us get instructions on how to build a real arm64 copy so that people can get something to use directly? We would like folks to not have to pay the compilation time to build us but don't have arm64-linux experience ourselves...

[danifv]

Can you help us get instructions on how to build a real arm64 copy so that people can get something to use directly? We would like folks to not have to pay the compilation time to build us but don't have arm64-linux experience ourselves...

Sure! Do you have a pipeline for building the x64 musl binaries? Would this pipeline work on arm64?
We basically did the following on our arm-based build host:

1. patched vcpkg with our custom bootstrap-vcpkg.sh
2. upon use a suitable binary was built

[BillyONeal]

Sure! Do you have a pipeline for building the x64 musl binaries?

Yes.

Would this pipeline work on arm64?

I don't believe so. We don't have arm64 hardware.

[danifv]

Would this pipeline work on arm64?

I don't believe so. We don't have arm64 hardware.

Unfortunately I don't have personal access to arm64 hardware, and as far as I've checked github.com actions/gitlab.com runners don't provide arm64 hardware either.
I'm not familiar with your infrastructure, but isn't qemu an option for you? Wouldn't this be easier to set up than to depend on 3rd party builds?

[BillyONeal]

I'm not familiar with your infrastructure, but isn't qemu an option for you?

I really don't have any idea. (This is kind of a "I lost my yo-yo." "Where did you have it last?" "Hey! If I knew that, I would still have my yo-yo!" situation)