Enable wasm32 compilation by wrapping libc #1362
Conversation
dalcde
changed the title
|
... so as I understand it, |
|
libc made a conscious decision to not support wasm32-unknown-unknown,
which makes sense since wasm doesn't come with any libc-like runtime.
For the purposes of building python extensions, this is less of a
problem, since we are building a dynamic library, to be loaded by an
emscripten runtime, which does provide libc-like functionalities.
An in any case, apart from the type definitions, all we need is
libc::atexit, which emscripten does happen to provide (should we provide
failsafes if it isn't present?)
There *is* a different target, wasm32-unknown-wasi, and wasi is a
standard for provide posix-like system calls in webassembly. libc is
working on an implementation for wasm32-unknown-wasi.
This wrapper is only enabled withen architecture = wasm32 and os =
unknown, so wasm32-unknown-wasi should use the "real" wasi-implemented
libc.
|
|
I see, thanks. In which case to have wasm32 support we're definitely going to need something like this. To keep the "wrapper" as small as possible, for all types we use which are exported in Let's see what's left after they're gone - I think except for |
| @@ -357,7 +357,7 @@ pub(crate) fn impl_wrap_setter( | |||
| #[allow(unused_mut)] | |||
| unsafe extern "C" fn __wrap( | |||
| _slf: *mut pyo3::ffi::PyObject, | |||
| _value: *mut pyo3::ffi::PyObject, _: *mut ::std::os::raw::c_void) -> pyo3::libc::c_int | |||
| _value: *mut pyo3::ffi::PyObject, _: *mut ::std::os::raw::c_void) -> ::std::os::raw::c_int | |||
There was a problem hiding this comment.
BTW, #1367 may conflict with this line (I'm sorry!) and you will need to merge that manually.
|
I think we can remove |
|
I think before resolving any rustc/wasm32 shenanigans, we can merge the
changes that convert `libc` to `std::os::raw` when applicable, which I
think is an positive change in any case (currently both are used,
seemingly arbitrarily)
|
Agreed - are you willing to factor those changes out into a separate PR? |
|
Agreed - are you willing to factor those changes out into a separate PR?
Sure
|
|
Closing in favor of #1368. May be reopened if this turns out to be useful/needed |
My plan is to use this with pyodide.
It is unclear how to test this at the moment. I think a reasonable solution is to make sure it compiles with
--target wasm32-unknown-unknownafter supplying suitable header files, possibly copying from pyodide, and run no tests. When/if things get ready with pyodide, we can consider running integration tests with it, but that would require a very different setup. Due to the nature of the builds, I also think it is unlikely that it can be usable without nightly in the near future.I'm also happy to leave this as a PR until then. See also #1221