xcm crate fails to compile in wasm32-unknown-unknown

[dzmitry-lahoda]

Steps

1. clone https://github.com/ComposableFi/composable/tree/dz/cosmwasm/xcm-executor/cosmwasm/contracts/xcm-executor
2. cd to ./cosmwasm/contracts/xcm-executor
3. Run cargo wasm
4. Build success with 0.9.25 version of xcm crate
5. In Cargo.toml set xcm = { git = "https://github.com/paritytech/polkadot", default-features = false, branch = "master" }
6. cargo wasm

Expected:

compiles well

Actual:

Fails with

dz@dz-pc-11:~/github.com/ComposableFi/composable/cosmwasm/contracts/xcm-executor$ cargo wasm
   Compiling sp-io v6.0.0 (https://github.com/paritytech/substrate?branch=master#e6768a3b)
error[E0152]: found duplicate lang item `panic_impl`
    --> /home/dz/.cargo/git/checkouts/substrate-7e08433d4c370a21/e6768a3/primitives/io/src/lib.rs:1688:1
     |
1688 | pub fn panic(info: &core::panic::PanicInfo) -> ! {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: the lang item is first defined in crate `std` (which `uint` depends on)
     = note: first definition in `std` loaded from /home/dz/.rustup/toolchains/nightly-2022-08-09-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib/libstd-f8f11a8217f9cded.rlib
     = note: second definition in the local crate (`sp_io`)

error[E0152]: found duplicate lang item `oom`
    --> /home/dz/.cargo/git/checkouts/substrate-7e08433d4c370a21/e6768a3/primitives/io/src/lib.rs:1704:1
     |
1704 | pub fn oom(_: core::alloc::Layout) -> ! {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: the lang item is first defined in crate `std` (which `uint` depends on)
     = note: first definition in `std` loaded from /home/dz/.rustup/toolchains/nightly-2022-08-09-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib/libstd-f8f11a8217f9cded.rlib
     = note: second definition in the local crate (`sp_io`)

For more information about this error, try `rustc --explain E0152`.
error: could not compile `sp-io` due to 2 previous errors

Notes

• same issue seems happens for other people (seems ink related works) Error when building contract with XCM. pallet-contracts-xcm#1

[bkchr]

You need to build with --no-default-features. Your crate is also not no_std.

[bkchr]

Xcm also compiles in Polkadot without any problems for wasm32-unknown-unknown.

[dzmitry-lahoda]

--no-default-features

this use used. had build --target wasm32-unknown-unknown --release --no-default-features"

[dzmitry-lahoda]

!no_std - seems issue. so after 0.9.25 seems something was added and need to sure coswasm also no_std

[dzmitry-lahoda]

need to make cosmwasm to be no_std to compile with xcm in one crate

[dzmitry-lahoda]

for thoose who will be here.

xcm. it either works in no_std (sp-io provides missing functions) or std env (rust std used).

cosmwasm contract crates are only std. these no_std because the run in wasm, but that is just hacky support of no_std.

so not sure how to compile xcm crate without forking cosmwasm crates and add no_std (and will sp-io functions work in cosmwasm?).

so may be can make somehow xcm to work in std.

[dzmitry-lahoda]

imho the fix would be xcm not to depend on sp-runtime, but may be on some simple libs. actually xcm compiles as long as ALL other cosmwasm dependencies and bloats contracts, which is not ideal for XCM to be name "Cross Chain"

[bkchr]

which is not ideal for XCM to be name "Cross Chain"

This is a weird take.

imho the fix would be xcm not to depend on sp-runtime

This is reasonable. You could create a pr or at least an issue, but before you should check the xcmv3 branch.

[dzmitry-lahoda]

v3 is better. not sp-runtime. but sp-core https://github.com/paritytech/polkadot/blob/gav-xcm-v3/xcm/Cargo.toml . so weird that until 0.9.25 inclusive it was working ok.

[bkchr]

It was probably not imported before?

[dzmitry-lahoda]

it works. v3 compiles with no_std

now i can complain to cosmos that they are not multichain because some of their crates are not no_std

[bkchr]

now i can complain to cosmos that they are not multichain because some of their crates are not no_std

You know, just because some implementation is not working for every target, it doesn't mean that it isn't multichain? You are mixing there the specification with the implementation. There can exist multiple implementations of the same specification and some of these implementations may being very opinionated.