Please publish release artefacts with GC and EH support #3829
Labels
Comments
|
Thanks for your suggestion, I modified the release CI to add the builds for x86 [Linux | macOS | Windows], and on Windows and Linux, test your wasi example, they can run successfully. |
|
🙌 Great! Thanks! |
|
How about Arm+macOS? |
wenyongh
pushed a commit
that referenced
this issue
Oct 21, 2024
… and Exception Handling (#3866) As suggested in #3829, in release CI, we add zip/tar.gz artifacts named iwasm-gc-eh-{version}-{platform} for `iwasm` which supports features garbage collection and exception handling(classic interpreter only). Also, add a command line option to control GC heap size for `iwasm` on the Windows platform.
|
I will look into arm macOS and it will probably be ready in the release after the next(next is 2.2.0, which will be released soon, so maybe release binaries can have arm+macOS in 2.2.1 or so), I want to test it more on the arm macOS but I don't have the environment right now. |
|
@TianlongLiang awesome! We are looking forward to it! |
Zzzabiyaka
pushed a commit
to Zzzabiyaka/wasm-micro-runtime
that referenced
this issue
Oct 22, 2024
… and Exception Handling (bytecodealliance#3866) As suggested in bytecodealliance#3829, in release CI, we add zip/tar.gz artifacts named iwasm-gc-eh-{version}-{platform} for `iwasm` which supports features garbage collection and exception handling(classic interpreter only). Also, add a command line option to control GC heap size for `iwasm` on the Windows platform.
|
@wenyongh super, thanks for the update! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature
To get GC and EH support, right now, we need to build WAMR from sources, which complicates
Ideally, we need builds for [Linux | macOS | Windows] * [x86 | Arm] (64-bit versions probably would be enough), though I'm not quite sure about Linux Arm, macOS x86.
Benefit
Having such binaries in releases may remove/reduce barriers to trying WAMR on wasm binaries requiring GC and EH support.
Also, in this case, it would be simpler for us to use WAMR in our compiler tests and examples
Alternatives
Someone else could do it, but official binaries are likely more trustworthy.
Also, it's simpler to keep such builds up to date inside the WAMR project.
The text was updated successfully, but these errors were encountered: