Comments (12)
It looks like it should be possible to modify bazel/emscripten_deps.bzl such that it makes the file extension depend on the version:
emsdk/bazel/emscripten_deps.bzl
Lines 102 to 132 in d52c465
If we did that then you could use emsdk main to install older versions.
from emsdk.
The wasm-binaries
archive swtich from tar.gz
to tar.xz
back in #1281, which seem like it must be related.
Are you saying that emscripten_bin_linux
is incorrect for older versions or newer versions? I would have thought it simply would not work for older versions since older versions use .tar.gz
.
Perhaps we could find a way to make emscripten_bin_linux
aware of the version?
Is there some reason you need/want to install those old versions?
Would it work if you used the same version of emsdk was emscripten_version? i.e. a version of emsdk prior to #1281?
from emsdk.
Are you saying that emscripten_bin_linux is incorrect for older versions or newer versions? I would have thought it simply would not work for older versions since older versions use .tar.gz.
What I am seeing is that the recent versions of emsdk (3.1.47+) are not working for older versions of Emscripten (e.g., 3.1.45). For example, if try to load Emscripten into my workspace like this:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "emsdk",
sha256 = "47515d522229a103b7d9f34eacc1d88ac355b22fd754d13417a2191fd9d77d5f",
strip_prefix = "emsdk-3.1.59/bazel",
url = "https://github.com/emscripten-core/emsdk/archive/refs/tags/3.1.59.tar.gz",
)
load("@emsdk//:deps.bzl", emsdk_deps = "deps")
emsdk_deps()
load("@emsdk//:emscripten_deps.bzl", emsdk_emscripten_deps = "emscripten_deps")
emsdk_emscripten_deps(emscripten_version = "3.1.45")
load("@emsdk//:toolchains.bzl", "register_emscripten_toolchains")
register_emscripten_toolchains()
Emsdk tries to fetch this invalid URL (404): https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/2b7c5fb8ffeac3315deb1f82ab7bf8da544f84a1/wasm-binaries.tar.xz
Note however that changing the extension manually to wasm-binaries.tar.gz also results in a 404.
Is there some reason you need/want to install those old versions?
I have a custom runtime and since the ABI is not stable and since I use Pyodide in my project, I pin the Emscripten version to the same version of Emscripten as the latest Pyodide release.
from emsdk.
I just tried emsdk 3.1.59 with emscripten 3.1.46 which downloads, however, the checksum for wasm-binaries.tar.xz doesn't line up with what emsdk expects.
Expected: 75cbf14629b06e417b597d3f897ad7d881c53762380aca2f0dd85f1b15891511
Got: 8346da51c82fdd67369a4f31b4bc9dcb8734ace945725124edf4289714c5a80d
from emsdk.
If you always match the emsdk version with the emscripten version does that work? That seems like your safest bet.
from emsdk.
It does work, although I was hoping that I could use a version of emsdk with 90d2168 and Emscripten 3.1.46.
from emsdk.
In order to make that work we would need to teach the bazel toolchains the pointer at which the filenames got renamed from tar.gz
to tar.gz
(for linux) and .tbz2
to .tar.bz
(for mac) .
This might be possible.. ?
from emsdk.
I believe the transition in filenames happened between 3.1.46 and 3.1.47.
The reason you are seeing the wrong sha hash is that for 3.1.46 it looks like we uploaded both the .tar.xz
and the .tbz2
file.
$ wget https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/21644188d5c473e92f1d7df2f9f60c758a78a486/wasm-binaries.tar.xz
$ wget https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/21644188d5c473e92f1d7df2f9f60c758a78a486/wasm-binaries.tbz2
$ sha256sum wasm-binaries.t*
8346da51c82fdd67369a4f31b4bc9dcb8734ace945725124edf4289714c5a80d wasm-binaries.tar.xz
75cbf14629b06e417b597d3f897ad7d881c53762380aca2f0dd85f1b15891511 wasm-binaries.tbz2
from emsdk.
I believe the transition in filenames happened between 3.1.46 and 3.1.47.
The reason you are seeing the wrong sha hash is that for 3.1.46 it looks like we uploaded both the
.tar.xz
and the.tbz2
file.$ wget https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/21644188d5c473e92f1d7df2f9f60c758a78a486/wasm-binaries.tar.xz $ wget https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/21644188d5c473e92f1d7df2f9f60c758a78a486/wasm-binaries.tbz2 $ sha256sum wasm-binaries.t* 8346da51c82fdd67369a4f31b4bc9dcb8734ace945725124edf4289714c5a80d wasm-binaries.tar.xz 75cbf14629b06e417b597d3f897ad7d881c53762380aca2f0dd85f1b15891511 wasm-binaries.tbz2
This only applies to 3.1.46, right? So the hash just needs to be adjusted or does fixing this still mean making bazel/emscripten_deps.bzl aware of the relationship between the version and the extension?
from emsdk.
I think the only real fix is to make bazel/emscripten_deps.bzl
aware of the relationship between the version and the extension.
from emsdk.
For the record, we noticed this too with https://github.com/mymindstorm/setup-emsdk in GitHub Actions, which started raising the same error when attempting to setup up emscripten 3.1.39.
It seems that action always downloads the latest main
branch from emsdk, regardless of the version
specified for emscripten. I'll file an issue there to suggest changing that behavior to check out the same branch for emsdk as the target emscripten version.
Edit: Done: mymindstorm/setup-emsdk#45
I'm not sure why things started breaking today though, when the latest emsdk main
commit was a week ago.
from emsdk.
Also, the transition of filenames happened months ago.
from emsdk.
Related Issues (20)
- Failed to install 3.1.7 HOT 2
- Set a version with available linux/arm64 release HOT 1
- how to install sdl2,boost_header when i offline HOT 2
- Won't Install HOT 24
- Encounter 404 Error when Installing Emscripten SDK Version 1.38.45 HOT 3
- CMake 3.28 and C++20, error: CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND HOT 11
- compile wams64 using bazel mode HOT 4
- Liblzma and other packages not being included in cmake compiling. HOT 5
- em++ hangs when run HOT 2
- Gf
- Support `--emit-tsd` in Docker container by default HOT 2
- undeclared identifier 'strtoll_l' and use of undeclared identifier 'strtoull_l' in c++\v1\locale HOT 2
- Bazel: Python3 not found HOT 3
- (bazel) cc-toolchain-wasm does not have mandatory providers: TemplateVariableInfo HOT 2
- emsdk activate breaks things HOT 1
- errors while running emmake make HOT 1
- Version of `wasm_cc_binary` that doesn't untar the result? HOT 4
- set -sMAXIMUM_MEMORY = 4GB & use uuid HOT 1
- [Bazel] [Potential solution] Cannot build multiple emscripten binaries in parallel with bazel HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from emsdk.