Closed ChanTsune closed 1 year ago
Hi! Thanks again for the very detailed PR. I looked more into wasm signal support since at first I thought it was some sort of bug that the signal emulation did not define sigset_t
or sigprocmask()
. This seems intentional however so your PR is certainly needed for a successful port to web assembly.
What you have so far seems like it is enough for liblzma to build, but we also should support an xz port. This should be easy to add just by following the example of VMS in src/xz/signal.*. Since the only functions in xz that use mythread_sigmask()
it should be enough to define signals_block() and signals_unblock() as no-ops in signal.h (and remove implementation from signal.c).
Let me know if you have questions or if something else is preventing us from building xz with wasi-sdk
On second thought, will be more complicated that I initially thought since signals_init()
needs to be disabled too. I will merge what you have once I make a fix for the xz side. Thanks for you contributions!
Thank you for your kind review!
I am honored to contribute to your project!
@ChanTsune We would like to add you to our THANKS file in the repository but were not sure what your name was. If you are interested in being credited in the THANKS file please let us know the name you would like credited since we could not find it on your GitHub profile.
Thanks again for your contribution!
Thank you! I updated my profile name. I would appreciate it if you could add this name to the THANKS file!
Thanks for the review #56 yesterday!
I tried another approach, could you please review this one?
Pull request checklist
Please check if your PR fulfills the following requirements:
Pull request type
Please check the type of change your PR introduces: - [ ] Bugfix - [ ] Feature - [ ] Code style update (formatting, renaming, typo fix) - [x] Refactoring (no functional changes, no api changes) - [x] Build related changes - [ ] Documentation content changes - [ ] Other (please describe): ## What is the current behavior?Related Issue URL:
56
What is the new behavior?
__wasm__
macro when the build target is set to wasm32 with clang. This change allowsliblzma
to be built with the platform-independentwasm32-uknown-unknown
target. I believe this exclusion will work in the same way as the build when targeting Windows, so it will minimize unexpected changes.Does this introduce a breaking change?
Other information
Build tested on docker
Dockerfile
If you need, you can see the predefined macros when targeting wasm32 in clang by following commands
or if you want to check with the latest wasi-sdk clang