#GHC s #wasm backend,native uses the native bignum backend and the wasm native #codegen Compared to the #gmp flavour, the run-time performance may be slightly worse if the workload involves big Integer operations. May be useful if you are compiling proprietary projects and have concerns about statically linking the #LGPL-licensed gmp library.
Besides wasm MVP, certain extensions are used. The feature flags are enabled globally in our wasi-sdk build, passed at GHC configure time, and the wasm NCG may make use of the features. The rationale of post-MVP wasm feature inclusion:
Non-browser non-JavaScript runtimes

wasmtime
wasmedge
toywasm
wasmi

Non-browser #JavaScript runtimes

node, using the builtin wasi module to provide WASI implementation
bun, using the builtin WASI implementation
deno, using a legacy WASI implementation in std
#browsers

WASI spec includes certain syscalls that are provided as the wasi_snapshot_preview1 wasm imports. Additionally, the current WASI ABI specifies two different kinds of WASI modules: commands and reactors.
When linking a program for almost any platform out there, the linker needs to handle ctors(constructors) & dtors(destructors). ctors and dtors are special functions that need to be invoked to correctly initialize/finalize certain runtime state. Even if the user program doesn't use ctors/dtors, as long as the program links to libc, ctors/dtors will need to be handled.

Add --export flag for malloc/free. You can now allocate and free linear memory buffers that can be visible to the Haskell world, since the entire linear memory is available as the memory export.
In the #Haskell world,
https://github.com/palas/ghc-wasm-meta