Coexistence of Rosetta 2 and ARM native binaries on Apple Silicon M1 Mac

[zacky1972]

Is your feature request related to a problem? Please describe.

Current asdf cannot have and switch both binaries of x86_64 with Rosetta 2 and ARM native on Apple SIlicon M1 Mac.

Describe the solution you'd like

• asdf can install both binaries.
• It can also run with the appropriate binary, automatically.

Describe similar asdf features and why they are not sufficient

asdf can have only one binaries corresponding to each version.

Describe workarounds you've considered

In case of Elixir and Erlang plugin, I use kerl instead of asdf.

Additional context

None.

[jthegedus]

Thinking out loud here. Supporting this will be difficult. Is it worth investing the effort when in just a couple years time we will only have M1 to support on macOS? People on non-M1 devices won't need this feature, so realistically it's only for early adopters of M1 devices, is that group large enough to warrant the refactor to support this?

[zacky1972]

@jthegedus I understand your position talk. I think it will be difficult, too.

[clakech]

Do you have stats about the usage of asdf by mac users / os version / specs ?

@jthegedus you suggest to tell to all M1 macOS asdf users to go for another tool for several years until most of mac users have moved to M1. asdf will have lost most of the macOS users by then. Will they come back ?

This group (M1 users) could be large enough quite soon IMO and implementing this huge feature takes time.

PS: I would like to be able to use asdf next year when I will change my laptop for a M1 😄

[jthegedus]

@clakech There may be some confusion here with what asdf is aiming to do and what the OP is asking for.

asdf is just bash scripts, so should run on Apple Silicon aarch64 as it does on x86.

asdf plugins can install binaries for any platform, the plugin is where the decision is made to install a binary for a particular OS or architecture. It is up to the plugin author to auto-detect this or offer the selection to the user. Plugins can detect OSs with uname -s and architectures with uname -i.

So asdf can support Apple Silicon and should not force Apple Silicon users to other tools.

The OP was asking for asdf to:

• support installing the same version of a tool for both x86 and aarch64 architectures on a single device (Apple Silicon).
• allow the user to switch between architectures for the same version of a tool

As an example, installing nodejs 14.15.4 x86 and nodejs 14.15.4 aarch64 on the same machine. Currently the plugin determines which architecture of a tool is installed and cannot install two versions of the same tool with different arch's.

---

Any upgrade required to get an Apple Silicon specific binary is required by each plugin, not the asdf core.

My earlier response was that we could potentially add support the OP wants to the core, but since Intel-based Apple devices will be phased out, and the use case is niche at best (same version of binary for two different architectures on same machine), then we shouldn't invest the time to support this in the core.

---

There is a way asdf plugins can offer what OP was asking without changes to the core. I will outline for documentation purposes.

Using the Java plugin as an example:

➜ asdf list all java
adoptopenjdk-8.0.162+12.openj9-0.8.0
...
corretto-8.202.08.2
...
corretto-musl-8.252.09.1
...
dragonwell-8.0.0
...
graalvm-19.0.0
...
java-se-ri-7u75-b13
...
liberica-1.8.0
...
liberica-javafx-8u242+7
...
liberica-lite-11
...
liberica-lite-musl-11.0.2
...
liberica-musl-8u262+10
...
mandrel-20.1.0.1.Final+java11
...
openjdk-9
...
sapmachine-11.0.6
...
trava-11.0.1+1
...
zulu-6.2.0.9
...
zulu-javafx-8.33.0.1
...
zulu-musl-8.33.0.1

We see that it supports multiple JVM tools from within the one plugin (I suspect it is auto-detecting OS and architecture). The "version" of a tool asdf supports is up to the plugin author to define, so if an author wanted to support specifying the architecture in the version name, they can. As an example, a plugin could list it's versions as <version-architecture> pairs, like this:

➜ asdf list all some_tool
0.0.1-x86_64
0.0.2-x86_64
0.0.1-aarch64
0.0.2-aarch64
# etc

Allowing a user to define both the version and architecture in .tool-versions

0.0.1-x86_64

and to switch they would just edit .tool-versions to the other architecture:

0.0.1-aarch64

This is the workflow the OP was asking for, but again, I caution the necessity of it given in a few years macOS devices will all be aarch64 and so use and support for both x86 via Rossetta2 and native Apple Silicon binaries on one device will also pass, let alone needing the exact same nodejs version on x86 and aarch64!

---

Do you have stats about the usage of asdf by mac users / os version / specs ?

We do not track users in asdf in any way that I am aware of.

Since we recommend git clone as the installation method, the GitHub stats for clones is useful for a count - https://github.com/asdf-vm/asdf/graphs/traffic

Homebrew also tracks install statistics - https://formulae.brew.sh/formula/asdf

OS/architecture/CPU specs would be interesting to know, but I don't believe asdf is ever going to have this type of tracking. I don't believe it will influence our decision to support the workflow the OP was after given there is an alternative at the plugin level should those authors decide the specific workflow is necessary.

[clakech]

@jthegedus thank you very much for your awesome answer. Seems like everything is fine ☺️

[jthegedus]

I am going to close this now. We can reopen should new people add to the discussion in a significant way that is not covered by my previous answer :)

[tanelmae]

I understand that the original question was aimed at having the same version for both architectures. The discussion is missing the point that the important utility asdf provides is dealing with legacy. In real setups that can sometimes mean 2-3 year old CLI tools. With increase of aarch64 devices this deficiency will just affect more people as ARM binaries are not available for old versions. Commenting here to just help people that find this issue with the same problem I faced.

There is a workaround to trick the asdf install to pick up legacy amd64 binaries instead. Would expect this to work with most plugins that try to detect the architecture.

Switch to x86_64 shell:

 /usr/bin/arch -x86_64 /usr/bin/env bash --login

Change the /usr/bin/env bash --login to match whatever shell you use.

Install some legacy binaries like this old version of Terraform:

asdf install terraform 0.12.31

Exit the x86_64 shell and continue using asdf