-
Notifications
You must be signed in to change notification settings - Fork 707
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
Can't build for IOS if referencing sp-core/std many library std libraries that link to sp-core/std #3909
Comments
Bindings for what crate? What Rust code are you trying to access rom IOS?
Can you not just set |
Sorry, that was a confusing way to say it. It's our own primitives library that I'm trying to link into an iOS client app. The app needs some substrate primitives and crypto functions that are linked to in the primitives library and the client that can also be run via CLI and over nodejs bindings. I'm using uniffi to create the iOS bindings. Since sp-runtime and sp-core both have primitives needed to interoperate with AccountIds, MultiSignatures, MultiSigners, Crypto primitives, etc, I've seen several projects link them in (subxt, parity-vault, our own stuff). |
@ggwpez Did that make sense? |
And with your patch it works? Maybe we can use that to disable WASMtime on IOS @bkchr ? |
It does resolve my issue locally. |
#3954 this should also solve your issue. |
@bkchr Even better. Thanks! |
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
I'm trying to build bindings for an IOS library, and when referencing some std libraries, they link back to sp-core/std, which has a dependency on wasmtime and will not allow building for IOS due to a lack of JIT. I have a shared crate that has references to several substrate types that I use in both the runtime and in the node. While trying to use this crate, I can't seem to unwind the dependency on sp-core/std that many libraries link back to. (The Parity Vault project is working around this by turning off std for both sp-core and sp-runtime. I would like to do this, but I have several substrate libraries, and was unable to unlink all the dependencies that eventually land one of them on linking to sp-core/std, and thus wasmtime.)
My question is - would you be open to either a flag turning off wasm in the core libraries and/or a flag that just disables linking to wasmtime on iOS. FWIW, that's what I did to resolve the issue for now (https://github.com/ulixee/polkadot-sdk/tree/release-polkadot-v1.9.0). I'm not sure if this is something that you'd be willing to support, as it might give the wrong impression that sp-core is runnable in iOS, but I'd love to have an option to include sp-core without this patch.
Steps to reproduce
The text was updated successfully, but these errors were encountered: