wasmtime / issue #14991 Build fails with `unsupported pla... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #14991 Build fails with `unsupported pla...

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:33):

Test Case

No Wasm file is needed: the wasmtime crate doesn't compile.

Steps to Reproduce

rustup target add x86_64-unknown-netbsd

In a Wasmtime checkout: cargo check -p wasmtime --target x86_64-unknown-netbsd

The same happens when building natively on NetBSD (aarch64 and x86_64) and on OpenBSD/aarch64.

Expected Results

wasmtime builds. On these targets it can't use signals to catch traps, but it can run without
them, the same as on platforms without a sys module or with Config::signals_based_traps(false).

Actual Results
error: unsupported platform
   --> crates/wasmtime/src/runtime/vm/sys/unix/signals.rs:361:13
    |
361 |             compile_error!("unsupported platform");
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: unsupported platform
   --> crates/wasmtime/src/runtime/vm/sys/unix/signals.rs:457:13
    |
457 |             compile_error!("unsupported platform");
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Versions and Environment

Wasmtime version or commit: main at ffff2e2db (also 47.0.4 and 36.0.19)

Operating system: NetBSD 10.1, OpenBSD 7.9 (and cross-checking x86_64-unknown-netbsd from macOS)

Architecture: x86_64 and aarch64 for NetBSD, aarch64 for OpenBSD

Extra Info

build.rs enables has_native_signals for every Unix target with a Cranelift backend, but
signals.rs only has code for reading and updating the signal context for some (OS, architecture)
pairs. #6962 reported the same error for NetBSD/OpenBSD in 2023 and is still open.

A fix could be to enable has_native_signals on Unix only for the pairs that signals.rs supports,
so other Unix targets build and use explicit checks instead of signals-based traps. Adding the
per-platform ucontext code would still be the way to get the faster path. A cargo check CI job
for x86_64-unknown-netbsd, next to the existing x86_64-unknown-freebsd one, could keep these
targets building, as suggested in #6962. I've opened #14990 along these lines.

For context, we maintain veil, a reverse proxy that embeds
Wasmtime for Proxy-Wasm plugins and ships builds for NetBSD and OpenBSD/aarch64. We currently vendor
Wasmtime with a build.rs patch to get past this error, and run Wasm with Pulley on these targets.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:33):

aofusa added the bug label to Issue #14991.

Wasmtime GitHub notifications bot (Oct 26 2026 at 22:47):

alexcrichton closed issue #14991:

Test Case

No Wasm file is needed: the wasmtime crate doesn't compile.

Steps to Reproduce

rustup target add x86_64-unknown-netbsd

In a Wasmtime checkout: cargo check -p wasmtime --target x86_64-unknown-netbsd

The same happens when building natively on NetBSD (aarch64 and x86_64) and on OpenBSD/aarch64.

Expected Results

wasmtime builds. On these targets it can't use signals to catch traps, but it can run without
them, the same as on platforms without a sys module or with Config::signals_based_traps(false).

Actual Results
error: unsupported platform
   --> crates/wasmtime/src/runtime/vm/sys/unix/signals.rs:361:13
    |
361 |             compile_error!("unsupported platform");
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: unsupported platform
   --> crates/wasmtime/src/runtime/vm/sys/unix/signals.rs:457:13
    |
457 |             compile_error!("unsupported platform");
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Versions and Environment

Wasmtime version or commit: main at ffff2e2db (also 47.0.4 and 36.0.19)

Operating system: NetBSD 10.1, OpenBSD 7.9 (and cross-checking x86_64-unknown-netbsd from macOS)

Architecture: x86_64 and aarch64 for NetBSD, aarch64 for OpenBSD

Extra Info

build.rs enables has_native_signals for every Unix target with a Cranelift backend, but
signals.rs only has code for reading and updating the signal context for some (OS, architecture)
pairs. #6962 reported the same error for NetBSD/OpenBSD in 2023 and is still open.

A fix could be to enable has_native_signals on Unix only for the pairs that signals.rs supports,
so other Unix targets build and use explicit checks instead of signals-based traps. Adding the
per-platform ucontext code would still be the way to get the faster path. A cargo check CI job
for x86_64-unknown-netbsd, next to the existing x86_64-unknown-freebsd one, could keep these
targets building, as suggested in #6962. I've opened #14990 along these lines.

For context, we maintain veil, a reverse proxy that embeds
Wasmtime for Proxy-Wasm plugins and ships builds for NetBSD and OpenBSD/aarch64. We currently vendor
Wasmtime with a build.rs patch to get past this error, and run Wasm with Pulley on these targets.

Last updated: Oct 31 2026 at 23:03 UTC