arm64-linux binaries are now available for all releases

[sbc100]

No description provided.

[sbc100]

@jamsinclair

[dschuff]

It looks like the builder didn't actually upload the binary (https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8751121556423129441/+/u/Archive_Binaries__aarch64_/stdout) I guess I need to fix the upload logic.

[dschuff]

If we want to test this, I can reproduce that build and upload it manually...

[sbc100]

If we want to test this, I can reproduce that build and upload it manually...

Oh.. so it only uploaded the one arch and not both?

If that is easy for you to do that would be great. Otherwise we can wait until the next release I guess

[dschuff]

Oh.. so it only uploaded the one arch and not both?

Yes. https://chromium-review.googlesource.com/c/emscripten-releases/+/5445121 should fix that.

If that is easy for you to do that would be great. Otherwise we can wait until the next release I guess

I think it shouldn't be too hard. I realized that with the build code as written the arch name is going to be 'aarch64' instead of 'arm64' which is what it looks like the emsdk code currently expects. This a mismatch with mac, but that's intentional because aarch64 is what the architecture is actually called on Linux (which doesn't match mac). I think it would be straightforward to change that in build.py though; do you have a preference?

[sbc100]

Oh.. so it only uploaded the one arch and not both?

Yes. https://chromium-review.googlesource.com/c/emscripten-releases/+/5445121 should fix that.

If that is easy for you to do that would be great. Otherwise we can wait until the next release I guess

I think it shouldn't be too hard. I realized that with the build code as written the arch name is going to be 'aarch64' instead of 'arm64' which is what it looks like the emsdk code currently expects. This a mismatch with mac, but that's intentional because aarch64 is what the architecture is actually called on Linux (which doesn't match mac). I think it would be straightforward to change that in build.py though; do you have a preference?

Lets stick with arm64 since that is what all the existing binaries already are called. I personally think name is way more readable too.

(aarch64 is such a strange choice of name since they waste 4 of the 5 letters on an abbreviation of "architecture" and only use a single letter for the useful part ("arm")).

[dschuff]

I don't disagree that the name is weird, but many things are still simpler if you match the name used by the system.
Not this though; I updated https://chromium-review.googlesource.com/c/emscripten-releases/+/5445121 to use arm64 instead.
Also I uploaded a local build, so we should be able to test this out now.

[sbc100]

I don't disagree that the name is weird, but many things are still simpler if you match the name used by the system. Not this though; I updated https://chromium-review.googlesource.com/c/emscripten-releases/+/5445121 to use arm64 instead. Also I uploaded a local build, so we should be able to test this out now.

nice!

[sbc100]

Worked for me locally:

$ EMSDK_ARCH=arm64 ./emsdk install latest
Resolving SDK alias 'latest' to '3.1.57'
Resolving SDK version '3.1.57' to 'sdk-releases-523b29e1b99a61069a2fa9f9d3cc9be1c4c53d4d-64bit'
WARNING: arm64-linux binaries are not available for all releases.
See https://github.com/emscripten-core/emsdk/issues/547
Installing SDK 'sdk-releases-523b29e1b99a61069a2fa9f9d3cc9be1c4c53d4d-64bit'..
Skipped installing node-16.20.0-64bit, already installed.
Installing tool 'releases-523b29e1b99a61069a2fa9f9d3cc9be1c4c53d4d-64bit'..
Downloading: /usr/local/google/home/sbc/dev/wasm/emsdk/downloads/523b29e1b99a61069a2fa9f9d3cc9be1c4c53d4d-wasm-binaries-arm64.tar.xz from https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/523b29e1b99a61069a2fa9f9d3cc9be1c4c53d4d/wasm-binaries-arm64.tar.xz, 284858280 Bytes
Unpacking '/usr/local/google/home/sbc/dev/wasm/emsdk/downloads/523b29e1b99a61069a2fa9f9d3cc9be1c4c53d4d-wasm-binaries-arm64.tar.xz' to '/usr/local/google/home/sbc/dev/wasm/emsdk/upstream'

[sbc100]

$ file upstream/bin/clang-19 
upstream/bin/clang-19: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, not stripped

[dschuff]

Oops, I raced with you on restarting the failed job and cancelled the wrong one. I just restarted again.

[dschuff]

Does this need the same 'install docker' and 'setup_remote_docker' steps as x64?

[sbc100]

It didn't have them before so I guess not? Not sure why.

[sbc100]

We can now suggest the arm64 folks try out the latest toolchain with ./emsdk install latest!

[jamsinclair]

Thanks for your hard work on this @sbc100! 🎉 🙇 Huge benefit for those of us on ARM based machines.

[sbc100]

You're welcome. You can really thank @dschuff for getting the cross build working.

Please let us know ASAP if these binaries are working.

[bvibber]

Thanks for this @sbc100 and @dschuff! :D :D It seems to compile object files ok, but is dying on calling the node-based closure compiler for me. Java isn't installed in the Linux VM or on the macOS host, where build is successful.

building:WARNING: falling back to java version of closure compiler
Command '['/home/brooke/src/emsdk/node/16.20.0_64bit/bin/node', '--max_old_space_size=8192', '/home/brooke/src/emsdk/upstream/emscripten/node_modules/.bin/google-closure-compiler', '--platform=java', '--version']' returned non-zero exit status 254.
emcc: error: closure compiler (/home/brooke/src/emsdk/node/16.20.0_64bit/bin/node --max_old_space_size=8192 /home/brooke/src/emsdk/upstream/emscripten/node_modules/.bin/google-closure-compiler --platform=java --version) did not execute properly!
make: *** [Makefile:294: build/ogv-demuxer-ogg.js] Error 1

on command line:

EMCC_COMMON_OPTIONS="
-O3
-s VERBOSE=1
-s ERROR_ON_UNDEFINED_SYMBOLS=0
-s INVOKE_RUN=0
-s NO_EXIT_RUNTIME=1
-s NODEJS_CATCH_EXIT=0
-s MODULARIZE=1
-s NO_FILESYSTEM=1
-s ALLOW_MEMORY_GROWTH=1
-s SINGLE_FILE=0
"

EMCC_WASM_OPTIONS="
"

EMCC_NOTHREAD_OPTIONS="
--closure 1
"

# compile wrapper around libogg + liboggz + libskeleton
emcc \
  $EMCC_COMMON_OPTIONS \
  $EMCC_WASM_OPTIONS \
  $EMCC_NOTHREAD_OPTIONS \
  -s EXPORT_NAME="'OGVDemuxerOgg'" \
  -s EXPORTED_FUNCTIONS="`< src/js/modules/ogv-demuxer-exports.json`" \
  -Ibuild/wasm/root/include \
  --js-library src/js/modules/ogv-demuxer-callbacks.js \
  --pre-js src/js/modules/ogv-module-pre.js \
  --post-js src/js/modules/ogv-demuxer.js \
  src/c/ogv-demuxer-ogg.c \
  src/c/ogv-buffer-queue.c \
  -Lbuild/wasm/root/lib \
  -lskeleton \
  -loggz \
  -logg \
  -o build/ogv-demuxer-ogg.js

If I try to manually re-install the node_modules inside ~/src/emsdk/upstream/emscripten it complains that arm64 Linux is not supported for google closure compiler:

~/src/emsdk/upstream/emscripten$ npm ci
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for [email protected]: wanted {"os":"linux","arch":"x32,x64"} (current: {"os":"linux","arch":"arm64"})
npm ERR! notsup Valid OS:    linux
npm ERR! notsup Valid Arch:  x32,x64
npm ERR! notsup Actual OS:   linux
npm ERR! notsup Actual Arch: arm64

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/brooke/.npm/_logs/2024-04-12T17_46_02_242Z-debug-0.log

Workaround: install java (apt install default-jre on Debian or Ubuntu) and it works fine with the Java version of closure compiler. Yay!! :D

[sbc100]

Thanks for testing Brooke!

I believe the issue is that the closure compiler npm module we depend on supplies native binaries, but I guess not for linux/arm64. See https://www.npmjs.com/package/google-closure-compiler-linux. The emscripten code handles this by falling back to --platform=java in this situation: https://github.com/emscripten-core/emscripten/blob/46bd566937e1559a6b732cc78666e5be08cc414d/tools/building.py#L496-L502

So I guess the best solution is to install java.. and then maybe file a bug on the https://www.npmjs.com/package/google-closure-compiler-linux package to ask for native support (which is faster).

[sbc100]

(Sorry I see now that you worked all that out on your own :)