How to generate standalone binary from .wasmu file

[darccio]

Summary

By default, it seems that wasmer compile generates a .wasmu file. According to #3014 (comment), it's already contains compiled machine instructions for the target arch.

From the same thread, it seems implied that using create-exe with a .wasmu should generate a standalone binary with Wasmer runtime embedded on it and the module converted and linked as object. This would seem to align with a old blog post in wasmer.io.

When I run the following instructions, I get an error about a bad magic number.

> wasmer compile hello_world.wat -o hello_world.wasmu # Find hello_world.wat in the Additional details section.
Compiler: cranelift
Target: x86_64-unknown-linux-gnu
✔ File compiled successfully to `hello_world.wasmu`.

> wasmer create-exe hello_world.wasmu -o hello_world
Compiler: cranelift
Target: x86_64-unknown-linux-gnu
Using path `/home/dario/.wasmer/cache/wasmer-linux-amd64/lib/libwasmer-headless.a` as libwasmer path.
error: Compilation error: WebAssembly translation error: Invalid input WebAssembly code at offset 0: magic header not detected: bad magic number - expected=[
    0x0,
    0x61,
    0x73,
    0x6d,
] actual=[
    0x77,
    0x61,
    0x73,
    0x6d,
]

Does create-exe supports compile output files or should we use another tool to generate a .wasm file - like wat2wasm - to feed it to create-exe?

Thanks!

Additional details

Wasmer version: wasmer 5.0.4

hello-world.wat:

(module
  ;; Import the required WASI functions
  (import "wasi_snapshot_preview1" "fd_write" (func $fd_write (param i32 i32 i32 i32) (result i32)))

  ;; Define a buffer to store the message
  (memory (export "memory") 1)
  (data (i32.const 8) "Hello, World!\n")

  ;; Define the _start function
  (func $main (export "_start")
    ;; Setup the iovec array
    (i32.store (i32.const 0) (i32.const 8))    ;; pointer to the message
    (i32.store (i32.const 4) (i32.const 14))   ;; length of the message

    ;; Call fd_write
    (call $fd_write
      (i32.const 1)  ;; file_descriptor - 1 for stdout
      (i32.const 0)  ;; *iovs - pointer to the iovec array
      (i32.const 1)  ;; iovs_len - number of iovec entries
      (i32.const 20) ;; nwritten - where to store the number of bytes written
    )
    drop ;; Discard the result
  )
)

[darccio]

Update: I converted the .wat file using wat2wasm and create-exe didn't complain but running the binary failed with a reference to wasmer-universal:

> wasmer create-exe hello_world.wasm -o hello_world
Compiler: cranelift
Target: x86_64-unknown-linux-gnu
Using path `/home/dario/.wasmer/cache/wasmer-linux-amd64/lib/libwasmer-headless.a` as libwasmer path.
✔ Native executable compiled successfully to `hello_world`.
> ./hello_world 
Failed to create module from atom "hello_world"
Error len: `65`
incompatible binary: The provided bytes are not wasmer-universal

This makes sense if create-exe only works with WASM Universal binaries.

[xdoardo]

Hello, thanks for the report. I'll investigate this as soon as possible.

[xdoardo]

Currently, create-exe only supports receiving .wasm files, but we can investigate how to make it happen.

[darccio]

Thanks @xdoardo. As I showed in #5422 (comment), using a .wasm returns an error mentioning bytes not being wasmer-universal.

What am I missing? I'd appreciate some orientation.

[wakabat]

Hey so I ran into the same problem, and did some digging. I've nailed down to this section of code, which I think might be the reason:

wasmer/lib/cli/src/commands/create_exe.rs

Lines 1079 to 1095 in aa2024f

	let obj_file = object::File::parse(&*object_file)?;
	let sections = obj_file
	.sections()
	.filter_map(|s| s.name().ok().map(|s| s.to_string()))
	.collect::<Vec<_>>();
	let section = obj_file
	.section_by_name(".data")
	.unwrap()
	.data()
	.map_err(|_| {
	anyhow::anyhow!(
	"missing section .data in object file {} (sections = {:#?}",
	object_file_src.display(),
	sections
	)
	})?;
	let metadata_length = section.len();

metadata_length should only keep the length of, well, the metadata symbol. However right now the code calculates all of the .data section. I've put together a sample fix in this commit, which IMHO should be the correct logic.

That being said, I have to mentioned that I ran into this issue using an older wasmer version(a fork from wasmer 4.3.7). It seems @darccio was also using an older version (5.0.4). In current tip of wasmer, the bug cannot be reproduced, I guess maybe the reason is that the metadata symbol remains the only thing wasmer 6.x decides to put in .data section. So the buggy code is never triggered in current tip. Still, I would think it's best if we fit the code in case data placement logic changes again in the future, what do you think?