wasmerio/wasmer · error

Unsupported backend kind {v:?}

Error message

Unsupported backend kind {v:?}

What it means

The From<BackendKind> impl for wasmer_backend_t maps Wasmer backend enum values to C API constants. Backend variants that are not covered by enabled compile-time features fall into the catch-all arm and panic with "Unsupported backend kind". The panic means the backend exists in the enum but was not compiled into this Wasmer build.

Source

Thrown at lib/c-api/src/wasm_c_api/engine/mod.rs:47

    /// The V8 backend.
    V8,
}

impl From<BackendKind> for wasmer_backend_t {
    fn from(value: BackendKind) -> Self {
        match value {
            #[cfg(feature = "cranelift")]
            BackendKind::Cranelift => Self::CRANELIFT,
            #[cfg(feature = "llvm")]
            BackendKind::LLVM => Self::LLVM,
            #[cfg(feature = "singlepass")]
            BackendKind::Singlepass => Self::SINGLEPASS,
            #[cfg(feature = "sys")]
            BackendKind::Headless => Self::HEADLESS,
            #[cfg(feature = "v8")]
            BackendKind::V8 => Self::V8,
            v => panic!("Unsupported backend kind {v:?}"),
        }
    }
}

impl Default for wasmer_backend_t {
    fn default() -> Self {
        // Let the `wasmer_api` crate decide which is the default engine, given the enabled
        // features.
        wasmer_api::BackendKind::default().into()
    }
}

/// An engine is used by the store to drive the compilation and the
/// execution of a WebAssembly module.
///
/// cbindgen:ignore
#[repr(C)]
// We can let the API decide which engine is default with the given set of

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Rebuild/obtain Wasmer with the needed feature enabled (e.g. cargo build --features v8 / singlepass / sys).
2. Before selecting a backend, check which backends the installed build supports (runtime introspection or documented feature set).
3. Add a fallback in your host code to a guaranteed-enabled backend when the preferred one is unavailable.
4. Verify you are not passing a headless/V8 kind where sys-family backends are required by the API you call.

Example fix

// before (Cargo.toml)
[dependencies]
wasmer = { version = "6", default-features = true } // no v8 feature
// after
[dependencies]
wasmer = { version = "6", features = ["v8"] }

// Check build capabilities before requesting a backend:
// maintain a list of enabled backends from your build and verify:
fn backend_available(kind: BackendKind, enabled: &[BackendKind]) -> bool {
    enabled.contains(&kind)
}

When it happens

Trigger: Creating a wasmer_backend_t from a BackendKind (e.g. V8, WASMI, Singlepass) whose corresponding cargo feature (v8, wasmi, singlepass, sys) was not enabled in the build; the match exhaustively handled only feature-gated variants and hit `v => panic!`.

Common situations: Using a prebuilt Wasmer binary/library that lacks the backend your code requests; enabling a backend at runtime through config while the library was compiled without it; version upgrades adding new BackendKind variants that older feature sets don't cover.

Related errors

• not a `sys` backend!
• unimplemented operator {operator:?}
• wasmer_env_set_memory() is not supported
• Unable to determine the wasmer dir: {e}
• cannot create debug directory: {}

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/1c0f510ee02f6446. Report an issue: GitHub.