Error with create-exe on Windows 11

[koduki]

Describe the bug

I tried to build executable file via create-exe for my wasm file. It works on Docker/Linux.
But when I tried it on Windows 11, i got below error.

> wasmer.exe create-exe -o .\hello.exe .\hello.wasm
Compiler: cranelift
Target: x86_64-pc-windows-msvc
Format: Symbols
error: Failed to find libwasmer

Wasmer version is 3.0.1

> wasmer --version
wasmer 3.0.1
> rustc --version
rustc 1.65.0 (897e37553 2022-11-02)

I can't find libwasmer under .wasmer directory. There are only wasmer.dll. Do I need something extra install?

PS C:\Users\koduki\.wasmer> dir .\lib\

    Directory: C:\Users\koduki\.wasmer\lib

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          2022/11/23    16:26       10873344 wasmer.dll
-a---          2022/11/23    16:26          70052 wasmer.dll.lib
-a---          2022/11/23    16:26       65993796 wasmer.lib

Steps to reproduce

1. Install wamer viaiwr https://win.wasmer.io -useb | iex
2. Install rust via winget install rustlang.rustup
3. Install Visual Studio 2022 and exec vcvars64.bat
4. exec via wasmer.exe create-exe -o .\hello.exe .\hello.wasm

hello.wasm was build via Rust and it was confirmed wamer run Linux(Docker) / Windows, and success create-exe on Linux.

Expected behavior

Success build and create executable file

Actual behavior

> wasmer.exe create-exe -o .\hello.exe .\hello.wasm
Compiler: cranelift
Target: x86_64-pc-windows-msvc
Format: Symbols
error: Failed to find libwasmer

Additional context

[GalaxyBlueReal]

I also have that issue, and it kinda stops me from testing it for windows.

[stevefan1999-personal]

Hmm, I hope this has nothing to do with UNC path?

PS C:\Users\steve\source\repos\ConsoleApp2\ConsoleApp2\bin\Debug\net7.0> wasmer create-exe .\ConsoleApp2.wasm -o .\ConsoleApp2.wasm.exe --enable-all --library-path C:/Users/steve/.wasmer/lib --target x86_64-pc-windows-gnu
Compiler: cranelift
Target: x86_64-pc-windows-gnu
Format: Symbols
Library Path: \\?\C:\Users\steve\.wasmer\lib
Using zig binary: C:\ProgramData\chocolatey\bin\zig.exe
Using zig target triple: x86_64-windows-gnu
error: error: unrecognized parameter: '-fstrip'

[stevefan1999-personal]

Now I got another error using LLVM...

PS C:\Users\steve\source\repos\ConsoleApp2\ConsoleApp2\bin\Debug\net7.0> wasmer create-exe .\ConsoleApp2.wasm -o .\ConsoleApp2.wasm.exe  --library-path C:/Users/steve/.wasmer/lib --target x86_64-pc-windows-gnu --llvm
Compiler: llvm
Target: x86_64-pc-windows-gnu
Format: Symbols
error: unimplemented symbol `wasmer_vm_raise_trap` kind Unknown

[fschutt]

@stevefan1999-personal @koduki It does have to do with UNC paths :/ The cross-compile test only runs on Mac and Linux in the CI, I do not remember why it's disabled for Windows. The UNC bug can be fixed with --library-path C:/Users/steve/.wasmer/cache/x86_64-windows-gnu/lib/libwasmer.a, but then it still fails with wasmer.h not found.

The unrecognized parameter: '-fstrip' error is an error that depends on your system zig version (it was a parameter in zig 0.10.0, but not in the latest version). The bug will be solved in 3.1 (in about a week).

Regarding the --llvm issue: I can reproduce it, I'll look into it. The C-API is not built with LLVM linking support, maybe that is the bug.

[koduki]

Thank you for your replay and actions. I got it. I'm looking forward to resolved version.

[syrusakbary]

Cross compiling to any OS using the llvm compiler currently fails:

wasmer/tests/integration/cli/tests/run.rs

Lines 44 to 50 in cdd71d3

	let excluded_combinations = &[
	("aarch64-darwin", "llvm"), // LLVM: aarch64 not supported relocation Arm64MovwG0 not supported
	("aarch64-linux-gnu", "llvm"), // LLVM: aarch64 not supported relocation Arm64MovwG0 not supported
	// https://github.com/ziglang/zig/issues/13729
	("x86_64-darwin", "llvm"), // undefined reference to symbol 'wasmer_vm_raise_trap' kind Unknown
	("x86_64-windows-gnu", "llvm"), // unimplemented symbol `wasmer_vm_raise_trap` kind Unknown
	];

We need a new ticket for this before closing current ticket @fschutt

[fschutt]

Seems like this bug is still not solved in 3.1, despite it working in the CI.

[fschutt]

#3430 will mostly fix this issue, except for compiling from Windows to Windows.

Basically we currently have no way to link with -lunwind (see #3459), which is required for the executables to work (Rust has little options to properly disable panicking).

So: generating a Linux binary from Windows will work now, only creating a Windows binary on Windows will fail (as a workaround, use Linux in a Docker container).