aarch64 build target for release

[neenjaw]

Hey @ee7 and @ErikSchierboom,

I switched platforms from ubuntu to macOS for my daily driver and noticed that configlet can't be fetched using the included repo script any more. Reading the documentation, I didn't see any method described to build it from source myself as a very poor nim user.

Could you advise?

Thanks

[ErikSchierboom]

This has been an open issue for a while IIRC. You should be able to use the x86 version by downloading it from an individual release. That said, this is not optimal and something we should fix.

[neenjaw]

No rush on it, I've found a way to circumvent this need 😄

https://github.com/exercism/php/blob/a88fadea963597af0c8980faef89cd0ad6ca01bb/.github/workflows/configlet-generate.yml

[ee7]

I've been planning to add aarch64 (AKA arm64) assets for some time. But in the meantime, I thought that fetch-configlet already downloaded the x86_64 asset when running on aarch64 macOS.

It looks like that, here:

configlet/scripts/fetch-configlet

Lines 26 to 30 in 18d9098

	case "$(uname -m)" in
	x86_64) arch='x86-64' ;;
	*686*) arch='i386' ;;
	*386*) arch='i386' ;;
	*) arch='x86-64' ;;

@neenjaw can you confirm that https://github.com/exercism/configlet/blob/main/scripts/fetch-configlet doesn't work on your machine? And if it doesn't, what happens?

Maybe it was just an intermittent connectivity issue? Or you were using an old fetch-configlet script? There was a breaking change in the asset naming scheme last year (see 57e6c5f), and 6 months after that I stopped supporting old fetch-configlet scripts.

[neenjaw]

So using the script at the link you shared:

curl https://raw.githubusercontent.com/exercism/configlet/main/scripts/fetch-configlet | bash

It seems to download configlet as expected but I still get a bash: line 86: ./bin/configlet: Bad CPU type in executable error which crashes with error code 127.

I think the fetch configlet script is still downloading the inappropriate version. I added this line above line 30 in the fetch-configlet script:

+    *arm*)  arch='arm64'  ;;
     *).     arch='x86-64' ;;

Which appears to work as expected now to fetch a runnable configlet

[ee7]

Hey @neenjaw, thanks for following up.

Indeed, we haven't yet updated the fetch-configlet script in either this repo or any track repo. Some rationale:

1. My understanding was that the existing fetch-configlet script has always worked on arm64 macOS, and it downloaded the x86_64 macOS configlet.
2. arm64 macOS can run an x86_64 macOS binary.
3. CI in this repo currently lacks native/emulated integration testing of the non-x86_64 binaries.
4. The x86_64 macOS binary probably doesn't perform strictly worse when running on arm64 macOS right now, because the arm64 macOS binary is built without link-time optimisation (as our linker doesn't yet support it).

I don't run macOS myself, so I don't know how automatic it is for arm64 macOS to run an x86_64 binary. But I thought it was pretty automatic.

Regarding:

curl https://raw.githubusercontent.com/exercism/configlet/main/scripts/fetch-configlet | bash

The fetch-configlet scripts weren't written with curl | bash in mind. So I want to confirm this isn't a curl | bash thing. Could you please run the below commands, and tell me what happens on your machine?

#!/usr/bin/env bash
git clone https://github.com/exercism/elixir temp-elixir-track
cd temp-elixir-track
bin/fetch-configlet # this script is identical to that in the configlet repo
file bin/configlet
bin/configlet --version
bin/configlet uuid

And could you confirm that you have Rosetta installed? If you didn't have Rosetta installed, but didn't get a good prompt to install it at the time of configlet execution, we should indeed make it a higher priority to modify the fetch-configlet script on each track to download the arm64 binary on arm64 macOS.

[neenjaw]

I have recreated the same error using elixir repository as advised. I don't get a prompt to install rosetta 2.

I manually installed rosetta with /usr/sbin/softwareupdate --install-rosetta, and it does succeed after that.

[ee7]

Ok, thanks!

[ee7]

But yeah, that's more friction than I assumed. Sorry for the inconvenience. I think we'll make closing #122 a higher priority, then.

In the meantime, feel free to use whichever binary you want :)

(But please let me know if you encounter anything unexpected with the arm64 binary).

[neenjaw]

the arm 64 binary seems to work as expected, no noted issues in the basic usage