-
Notifications
You must be signed in to change notification settings - Fork 2
Fix WASI build #17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 3.15-rust-in-cpython
Are you sure you want to change the base?
Fix WASI build #17
Conversation
4b23341 to
3cb965b
Compare
Looks like the system headers are not found correctly by bindgen, I wonder if we need to find wasi-libc/wasi-sdk ourselves. Ideally we'd make sure it's the same as the one found in https://github.com/python/cpython/blob/main/Tools/wasm/wasi/__main__.py, perhaps that script can pass an environment variable the build.rs can read? |
3cb965b to
40142ed
Compare
configure.ac
Outdated
| ;; | ||
| wasm32-unknown-wasip1) | ||
| CARGO_TARGET=wasm32-wasip1 | ||
| export BINDGEN_EXTRA_CLANG_ARGS="--sysroot=/opt/wasi-sdk/share/wasi-sysroot" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the WASI build script already sets WASI_SDK_PATH and WASI_SYSROOT https://github.com/Rust-for-CPython/cpython/blob/3.15-rust-in-cpython/Tools/wasm/wasi/__main__.py#L285-L286, perhaps it'd be better to just update the build.rs script to check if WASI_SYSROOT is set and add the argument there? Alternatively, you could set this environment variable in the WASI build script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it doesn't help, the error is not in this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I misunderstood the error. With WASI, modules are statically linked into libpython, so the error is that the linker isn't finding the PyInit__base64 symbol despite the linker hacks we have in place. In CPython modules can be build either statically or dynamically linked to libpython (which can depend on the platform. Finding a good solution to that seems important.
40142ed to
e1d688d
Compare
No description provided.