Error downloading wasm-binaries for <= 3.1.45 (if using `main` with ./emsdk install <version>)

[sogaiu]

I'm not having luck retrieving wasm-binaries when running ./emsdk install <version> for <version> <= 3.1.45. This is when on the main branch (at the time of writing the commit is at d09b3c38).

It looks like if I checkout a tag that matches the version (e.g. tag 3.1.45 for version 3.1.45), things can work...

Any chance of some changes in the direction of not having to checkout a matching tag?

I've come across the possibly related issue:

• https://github.com/emscripten-core/emsdk/issues/1379

Some transcripts follow.

Basic info:

$ git checkout main
Already on 'main'
Your branch is up to date with 'origin/main'.
$ git rev-parse HEAD
d09b3c3815479d80117d070882a91310f35c52b3

Download error for 3.1.45:

$ ./emsdk install 3.1.45
Resolving SDK version '3.1.45' to 'sdk-releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'
Installing SDK 'sdk-releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'..
Skipped installing node-18.20.3-64bit, already installed.
Installing tool 'releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'..
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1/wasm-binaries.tar.xz': HTTP Error 404: Not Found
^C

Download success for 3.1.46:

$ ./emsdk install 3.1.46
Resolving SDK version '3.1.46' to 'sdk-releases-21644188d5c473e92f1d7df2f9f60c758a78a486-64bit'
Installing SDK 'sdk-releases-21644188d5c473e92f1d7df2f9f60c758a78a486-64bit'..
Skipped installing node-18.20.3-64bit, already installed.
Installing tool 'releases-21644188d5c473e92f1d7df2f9f60c758a78a486-64bit'..
Downloading: /tmp/emsdk/downloads/21644188d5c473e92f1d7df2f9f60c758a78a486-wasm-binaries.tar.xz from https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/21644188d5c473e92f1d7df2f9f60c758a78a486/wasm-binaries.tar.xz, 257708108 Bytes
Unpacking '/tmp/emsdk/downloads/21644188d5c473e92f1d7df2f9f60c758a78a486-wasm-binaries.tar.xz' to '/tmp/emsdk/upstream'
Done installing tool 'releases-21644188d5c473e92f1d7df2f9f60c758a78a486-64bit'.
Done installing SDK 'sdk-releases-21644188d5c473e92f1d7df2f9f60c758a78a486-64bit'.

[sbc100]

I think prior to 3.1.46 the file extension used was .tbz2 and not .tar.xz. However we have code in emsdk that is supposed to fall back to the old filename when the new one fails.

When I try to install 3.1.45 is see the error, but then I see successs:

$ ./emsdk install 3.1.45
Resolving SDK version '3.1.45' to 'sdk-releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'
Installing SDK 'sdk-releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'..
Skipped installing node-18.20.3-64bit, already installed.
Installing tool 'releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'..
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1/wasm-binaries.tar.xz': HTTP Error 404: Not Found
Downloading: /usr/local/google/home/sbc/dev/wasm/emsdk/downloads/2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-wasm-binaries.tbz2 from https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1/wasm-binaries.tbz2, 344484986 Bytes
Unpacking '/usr/local/google/home/sbc/dev/wasm/emsdk/downloads/2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-wasm-binaries.tbz2' to '/usr/local/google/home/sbc/dev/wasm/emsdk/upstream'
Done installing tool 'releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'.
Done installing SDK 'sdk-releases-2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1-64bit'.

Note the failed attempt to fownload the .tar.xz followed by the successful download of the .tbz2.

The code for this fallback is here: https://github.com/emscripten-core/emsdk/blob/d09b3c3815479d80117d070882a91310f35c52b3/emsdk.py#L1399-L1409

I'm not sure how that code doesn't seem to be running for you.

[sogaiu]

My bad.

I misintrepreted the output (in my original post I have a manual interruption after the initial failure). I confirm there is a subsequent download that succeeds (also tried for lower versions such as 3.1.3 where I see similar behavior).

Sorry for the trouble!