Create manifest SDK entries for ARM64 emscripten-releases builds #816
Conversation
This allows emsdk to download the new ARM64 binaries from the emscripten-releases builders.
|
I'm not sure how to test this in the repo. If you have an arm64 mac you can test it manually by installing |
|
How have folks been installing the x64 pre-builts on arm64 so far? I though we did some hack to make that work but I can't find it now. @juj might know. |
|
See #671 |
|
Ah, that hack didn't land yet so there is currently no way to easily install the x86 binaries on arm. See #771 |
| "version": "upstream-%releases-tag%", | ||
| "bitness": 64, | ||
| "arch": "aarch64", | ||
| "macos_url": "https://storage.googleapis.com/webassembly/emscripten-releases-builds/mac/%releases-tag%/wasm-binaries-arm64.tbz2", |
There was a problem hiding this comment.
Is there a contextual difference between aarch64 and arm64? I see one in the URL and one in the arch field.
Best answer I found was this: https://stackoverflow.com/a/47274698/1176841
There was a problem hiding this comment.
To my understanding it should be the same thing, but python reports the field using different strings on linux and mac M1 it looks like.
There was a problem hiding this comment.
Yes, they are the same thing, and that's a pretty good summary of some reaasons the nomenclature varies. It was pretty amusing in LLVM during the time that ARM was developing their aarch64 backend upstream, while meanwhile it was the industry's worst-kept secret that apple was developing their own arm64 hardware for iOS devices and likely had their own private backend. Eventually they did merge the backends using some code and approaches from both (they also poached the engineer from ARM that led the upstream implementation; I'm sure that helped 😁 )
Anyway, in this patch I just kept aarch64 in the manifest since it was already there but most of the filenames have arm64 in them.
There was a problem hiding this comment.
Why not use aarch64 in the filenames too.. given that we control them?
There was a problem hiding this comment.
arm64 is more consistent with the binaries we don't control, e.g. python and node; and with other tools on mac (e.g. uname and Python's platform.machine()
There was a problem hiding this comment.
Annoying that we have to live with two names :( oh well..
There was a problem hiding this comment.
We had the same problem with amd64/x86_64... apparently we never learn from our mistakes. (Although to be fair, we do seem to have mostly converged on x86_64 over time, so maybe we will here too...)
I think we did not land a solution for that yet. Maybe a |
This allows emsdk to download the new ARM64 binaries from the emscripten-releases builders.
This allows emsdk to download the new ARM64 binaries from
the emscripten-releases builders.