2.0.33 #922
Merged
2.0.33 #922
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kripken
approved these changes
Nov 1, 2021
sbc100
force-pushed
the
version_2_0_33
branch
4 times, most recently
from
465b762 to
4134ce1
Compare
|
Rebased on top of #924 |
sbc100
force-pushed
the
version_2_0_33
branch
from
4134ce1 to
e8aceb4
Compare
I add to temporarily disable the test_binaryen_from_source test under macOS to work around: WebAssembly/binaryen#4299
sbc100
force-pushed
the
version_2_0_33
branch
from
e8aceb4 to
bde45d9
Compare
|
Do we want to do an LTO version? |
dschuff
reviewed
Nov 1, 2021
| @@ -232,6 +232,8 @@ def test_specific_version_full(self): | |||
| run_emsdk('activate sdk-tag-1.38.33-64bit') | |||
|
|
|||
| def test_binaryen_from_source(self): | |||
| if MACOS: | |||
| self.skipTest("https://github.com/WebAssembly/binaryen/issues/4299") | |||
There was a problem hiding this comment.
I don't really see how this is better than just committing #924. But I don't feel strongly about it.
There was a problem hiding this comment.
The main difference is that all the tools that emskd builds will still be 10.11 compatible.
if you try to build binaren latest or tot form source you will get a build error.. which is better than silently building a less-compatible version of binaryen perhaps?
There was a problem hiding this comment.
Oh I see, if you try to build older builds they will still work and be compatible. makes sense.
lewing
referenced
this pull request
in dotnet/emsdk
Jan 28, 2022
* Improve emscripten-releases-tags.txt to support mutliple aliases (#837) Also, improve reporting of version resolution. e.g.: ``` $ ./emsdk install sdk-latest Resolving SDK alias 'latest' to '2.0.23' Resolving SDK version '2.0.23' to 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit' Installing SDK 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit'.. ... ``` * bugfix: allow to install SDK binaries alone (#834) * 2.0.24 (#839) * Error out on attempt to activate a missing tools (#838) Previously if a tool (any part of an SDK) was not installed we would issue a warning and continue to active without returning non-zero. This meant doing `emsdk install 2.0.0 && emsdk activate latest` would appear to be work aside from the warning messages about latest not being installed. This is especially annoying since we dropped support for side by side SDK installations. The following sequence is no longer valid and we want to make that clear by erroring out: ``` $ emsdk install 2.0.1 $ emsdk install 2.0.2 $ emsdk activate 2.0.1 ``` Since 2.0.2 replaces 2.0.1 on the filesystem the active here could fail hard rather than just warning. * Consistent error messages (#840) * Point zsh and csh users to the correct startup script (#843) Fixes: emscripten-core/emscripten#14446 * Print sys.argv when link_wrapper.py is invoked incorrectly (#847) This should help debug cases when the link_wrapper is not invoked correctly. * Support linking with `-o filename` (#849) When linking with `-o filename` (such as in various CMake build checks), the parameter passed to the linker is a temporary file, and it is passed as a bare filename (i.e. relative path without a `'/'`). In such cases, `outdir` would have been the empty string, and the final `tar` command would fail (actually the call to `subprocess.check_call(…)` is what fails). * 2.0.25 (#850) * 2.0.26 (#858) * 2.0.26-lto (#861) * 2.0.27 (#868) Includes LTO and non-LTO, with non-LTO as the default * 2.0.28 (#871) * Use `.json` extension for emscripten-releases-tags.json. NFC (#870) * Add LTO build for 2.0.28 (#873) * Small fix for Bazel instructions. (#875) In the past the instructions were to copy `emscripten_toolchain` into the project dir, now it downloads emsdk as a package so the `bazelrc` part has to refer to `@emsdk`. * Version 2.0.29 (#878) * 2.0.29-lto (#881) * Fix release name for 2.0.29-lto (#885) Fixes #884 * [Bazel] fix llvm bin path (#888) * Add arm64 fastcomp releases to emsdk_manifest.json (#891) This was missing from emsdk_manifest.json and should alow older fastcomp SDKs to be install on M1 apple hardware (in emulation mode). Fixes: #889 * 2.0.30 (#893) * Fix error handling: untargz() in emsdk.py (#895) Make untargz() in emsdk.py return False if tar command failed. * Fix passing -DLLVM_ENABLE_PROJECTS directive to CMake - it does not want to see double quotes in the field passed to it. (#898) * Fix emscripten-version parsing (#902) See emscripten-core/emscripten#15144 * 2.0.31 (#906) * bazel: pass -g instead of -g4 for wasm_asan feature (#904) * Add embind example to Bazel docs (#910) * Add embind example to Bazel docs * address feedback * Run buildifier on bazel/ (#913) * Update build_bazel_rules_nodejs to fix closure compiles (#912) * Update build_bazel_rules_nodejs to fix closure compiles * Fix spacing in update_bazel_workspace.sh script * space * 2.0.32 (#915) * Improve flags in bazel example (#917) * Add back node.js 12.18.1 packages for Windows 7 support. (#877) * Update CMAKE_OSX_DEPLOYMENT_TARGET from 10.11 to 10.14 (#924) Apparently 10.11 is no longer good enough to run the latest version of binaryen. Specifically since binaryen switched to using std::variant it now fails to build with this set to 10.11. This is also the version used on the emscripten-releases CI which builds the emsdk binaries: https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#673 * Revert "Update CMAKE_OSX_DEPLOYMENT_TARGET from 10.11 to 10.14 (#924)" This reverts commit 99e5e02. * 2.0.33 (#922) I add to temporarily disable the test_binaryen_from_source test under macOS to work around: WebAssembly/binaryen#4299 * 2.0.34 (#925) * Bump EmscriptenVersion to 2.0.34 * Fix bad edit Co-authored-by: Sam Clegg <sbc@chromium.org> Co-authored-by: Yulong Wang <yulong.fs@gmail.com> Co-authored-by: Attila Oláh <attilaolah@gmail.com> Co-authored-by: Attila Oláh <atl@google.com> Co-authored-by: Derek Schuff <dschuff@chromium.org> Co-authored-by: Danny B <danila.bespalov@gmail.com> Co-authored-by: Brad Kotsopoulos <bkotsopoulos@snapchat.com> Co-authored-by: Matt Gucci <matt9ucci@gmail.com> Co-authored-by: juj <jujjyl@gmail.com> Co-authored-by: walkingeyerobot <mitch@thefoley.net> Co-authored-by: Kevin Lubick <kjlubick@users.noreply.github.com> Co-authored-by: Larry Ewing <lewing@microsoft.com>
akoeplinger
pushed a commit
to akoeplinger/emsdk
that referenced
this pull request
Dec 13, 2024
…0240909.2 (emscripten-core#922) Microsoft.NETCore.Runtime.Wasm.Emscripten.Transport From Version 9.0.0-alpha.1.24452.1 -> To Version 9.0.0-alpha.1.24459.2 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I add to temporarily disable the test_binaryen_from_source test
under macOS to work around:
WebAssembly/binaryen#4299