Quick hack to treat macOS-arm64 as macOS-x86_64 #771
Conversation
This gets things working with the x86_64 binaries under emulation on an Apple Silicon Mac. It's not ideal, as the compiler will run slower and use more memory than it would without emulation, but users may use their Macs as web developer workstations.
| @@ -116,6 +116,9 @@ def errlog(msg): | |||
| ARCH = 'x86' | |||
| elif machine.startswith('aarch64') or machine.lower().startswith('arm64'): | |||
| ARCH = 'aarch64' | |||
| if MACOS: | |||
| # arm64 macOS runs x86_64 binaries and we don't have build bots yet for native | |||
| ARCH = 'x86_64' | |||
There was a problem hiding this comment.
Can we instead have a command line option to opt into this? --arch=x86_64
Or an environment variable EMSDK_ARCH=x86_64?
With #753 we now support native python and node, although it only works in "build from source" mode. This change as it stand would render that path unavailable, no?
There was a problem hiding this comment.
I don't think we should use a command-line option; rather it should "just work". However using the Aarch64 node and python would be much preferable. What would you recommend for fetching the llvm & binaryen binaries for "x64" while fetching node and python from Aarch64?
There was a problem hiding this comment.
(You are using binaries of python and node right? Or do I misunderstand and those are from source too?)
There was a problem hiding this comment.
If it's possible to build the macOS binaries as universal binaries with the current SDK, that would be nice too -- then we wouldn't have to do any of this except fetching Aarch64-capable node and python.
There was a problem hiding this comment.
Does anyone know the exact build scripts used to produce the llvm/clang and binaryen binary artifacts? I would like to modify them to resolve this once and for all. ;)
There was a problem hiding this comment.
(Note that Node builds as aarch64 on mac, but they're still working on official universal binaries...)
There was a problem hiding this comment.
Universal binaries also double the download side right... I'm not sure we need/want that. Why not just build twice and upload two different archives?
|
Instead I would recommend adjusting emsdk_manifest.json so that it advertises the x86_64 versions of prebuilt Emscripten/LLVM/Binaryen binaries as compatible for ARM macOS. That way ARM macOS can continue using native python, while downloading only the x86 precompiled binaries. Once the CDN starts hosting arm64 precompiled binaries, emsdk_manifest.json can then be flipped to serve those instead. |
Agreed, this sounds like a good approach. |
|
Would be nice if circleci or github actions could provide some testing of this too .. |
Looks like its coming soon: |
|
I guess we don't need this anymore now that we have #816 in the works? As a developer I'd still love to have a way to fake the platform in emsdk so that I can, for example, download the install the mac SDK on my linux machine from time to time if I need to check something, but don't have a mac. |
Proposed temporary workaround for Apple Silicon (M1/ARM/Aarch64) Macs: treat arm64 on macOS as x86_64 instead, fetching the precompiled x64 binaries which work under emulation at some cost of performance.
This gets things working with the x86_64 binaries under emulation on an Apple Silicon Mac. It's not ideal, as the compiler will run slower and use more memory than it would without emulation, but users may use their Macs as web developer workstations.
This is not ideal; python and node should use native arm64 builds or universal binaries if possible. Ideally the binaryen and clang/llvm tools would be built as universal binaries or else separately for both architectures if that's not possible.