bytecodealliance / cargo-component

A Cargo subcommand for creating WebAssembly components based on the component model proposal.
Apache License 2.0
480 stars 55 forks source link

Does not link `env` module when compiling libs with `[no_std]` #333

Open Loara opened 2 months ago

Loara commented 2 months ago

cargo component build fails to compile Rust libraries with [no_std] flags because it cannot resolve the env import interface:

error: failed to decode world from module

Caused by:
    0: module was not valid
    1: module requires an import interface named `env`

Minimum reproducible example:

src/lib.rs (it uses an allocator from the lol_alloc crate)

#![no_std]

extern crate alloc;
extern crate lol_alloc;

#[allow(warnings)]
mod bindings;

#[global_allocator]
static ALLOCATOR : lol_alloc::FailAllocator = lol_alloc::FailAllocator;

#[panic_handler]
fn panic(_i : &core::panic::PanicInfo) -> ! {
    core::arch::wasm32::unreachable()
}

use bindings::Guest;
use alloc::string::{String, ToString};

struct Component;

impl Guest for Component {
    /// Say hello!
    fn hello_world() -> String {
        "Hello, World!".to_string()
    }
}

bindings::export!(Component with_types_in bindings);

wit/world.wit

package component:nostd;

/// An example world for the component to target.
world example {
    export hello-world: func() -> string;
}
primoly commented 1 month ago

For what it’s worth, the compilation succeeds but the final output wasm imports the symbols "env" "memset" and "env" "memcpy".

To avoid this you can use RUSTFLAGS='-C target-feature=+bulk-memory' cargo component build to generate a wasip1 component which depends on the widely supported^1 bulk memory operations.

Alternatively you can use cargo component build --target wasm32-unknown-unknown to generate a non Wasi component instead.