ashtonmeuser/godot-wasm

Windows MSVC build looking for Wasmer dynamic library

Closed this issue ยท 21 comments

fire commented

When I download from a github action godot engine fails to execute.

Expected to use a static library.

A .dll side by side is not so good.

A little more context here might help. I'll add an issue template at some point to prompt for some more details.

Godot version: V-Sekai/godot@dcd050b
Godot Wasm version: V-Sekai@74e5278
OS: Microsoft Windows Server 2022 10.0.20348
Build target platform: Windows (MSVC)

@fire Is the compiled editor looking for the Wasmer DLL or the Godot Wasm DLL? Can you add the actual error?

fire commented

The compiled editor is looking for a wasmer.dll. If you place it beside the executable it should work.

I prefer to somehow have a static library so instead of three binaries [godot.exe, wasmer.dll, game.pck] it'll be two [godot.exe, game.pck] and one binary if we embed the pck [game.exe].

Makes total sense. Wonder if changing the Wasmer library suffix to .lib rather than .lib.dll would do the trick.

That's a separate issue, no? Your build is using MSVC which downloads https://github.com/wasmerio/wasmer/releases/download/v3.1.1/wasmer-windows-amd64.tar.gz which contains static .lib libs.

Edit: Also, looks like there is a static .a file in the release you linked. Am I missing something?

fire commented

Ah mistaken. Let me check

fire commented

image

Not sure how we got here.

Hey it's one step closer! At least the engine compiles. I've dusted off the ol' Windows box so will have a better idea of what's happening. In the meantime, is it worth trying to load with a DLL present? Might tell us if there are any further issues.

fire commented

Testing

> git diff
diff --git a/modules/wasm/SCsub b/modules/wasm/SCsub
index 0d1906da742..09e00993b9a 100644
--- a/modules/wasm/SCsub
+++ b/modules/wasm/SCsub
@@ -16,7 +16,7 @@ elif env["platform"] in ["osx", "macos"]:
     module_env.Append(CXXFLAGS=["-std=c++17"])
     env.Append(LINKFLAGS=["-framework", "Security"])
 elif env["platform"] == "windows":
-    env["LIBWASMERSUFFIX"] = ".dll.lib"
+    env["LIBWASMERSUFFIX"] = ".lib"
     if env.get("use_mingw"):
         env["LIBWASMERSUFFIX"] = ".a"
         env.Append(LIBS=["userenv"])
fire commented

I'll kludge it by disabling the wasmer module compiling for msvc but keeping mingw support while I wait.

Looks like when Godot Wasm was swapped to use static libs (f8a84cf), no change was made to MSVC compilation. Same problem exists for all MSVC builds. See below for dependencies of the DLL created for Godot 3.x GDNative addon.

Screenshot 2023-05-06 172015

I've got a fix for this but haven't had much of a chance to implement today. Will update shortly.

fire commented

I saw an update!

Should be fixed with 29356da (Godot 3.x) and 2999e89 (Godot 4.x).

The root cause was an issue with statically linking Wasmer which in turn is caused by an issue with the Wasm C API. I've fixed it with a hotpatch and will open an issue upstream.

Explanation

I didn't fully understand how C libraries in Windows worked. TL;DR: A .lib file can be either a static library or an import library. A DLL isn't a perfect metaphor for a *nix dynamic library as it hides its symbols. It requires an import library (also .lib extension) to expose symbols. Wasmer provides both static and dynamic libraries in their Windows release artifact and differentiates the two with .lib and .dll.lib, respectively.

The Wasm C API (and thus Wasmer) assume all Windows implementations use the DLL by calling __declspec(dllimport) if the _WIN32 define is present e.g. Windows or MinGW. Using the static .lib with __declspec(dllimport) was declaring but not defining symbols (citation needed; I'm out of my depth here).

Very related to #26. In fact, we nearly accidentally solved this. The other piece of information that lead to the solve is here: wasmerio/wasmer#3298. Interestingly, the exact bug in Wasmer/Wasm C API was pointed out by a user there but I dismissed it in favour of dynamic linking. Didn't recall this when moving to static linking in f8a84cf.

@fire I'll keep an eye on your build. Let me know if we're good to close this.

fire commented

I am having trouble applying the patch on windows 11 on the windows command prompt with msvc.

Also, LINK : fatal error LNK1181: cannot open input file 'userenv.lib.windows.editor.double.x86_64.lib'

Checking if it's a problem with my merge.

FYI, you can run a windows 11 vm on linux / mac with no licensing fees for about a month. https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

fire commented

The build failed on Github actions.

Engine build failed and template build failed.

link @C:\Users\RUNNER~1\AppData\Local\Temp\tmpi87egrjz.lnk
   Creating library bin\godot.windows.template_release.x86_64.lib and object bin\godot.windows.template_release.x86_64.exp
wasmer.lib(std-2e5a4fde2066d4f2.std.db95cb0e-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol __imp_GetUserProfileDirectoryW referenced in function _ZN3std3env8home_dir17hca690f225b519101E
bin\godot.windows.template_release.x86_64.exe : fatal error LNK1120: 1 unresolved externals
scons: *** [bin\godot.windows.template_release.x86_64.exe] Error 1120
scons: building terminated because of errors.
[Time elapsed: 00:51:36.272]
Error: Process completed with exit code 2.

This doesn't feel related to Godot Wasm but I could be wrong. No idea what's going on. Lemme check on my end. I should really set up a minimal module build workflow for this repo.

Nice find! Guess we can take out the MinGW check but that might put us back to exactly #27.

fire commented

Fixed.