Windows MSVC build looking for Wasmer dynamic library
Closed this issue ยท 21 comments
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?
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.
Does https://github.com/wasmerio/wasmer/releases/download/v3.3.0/wasmer-windows-gnu64.tar.gz provide static libs?
I don't see evidence of this.
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?
Ah mistaken. Let me check
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.
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"])
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.
I've got a fix for this but haven't had much of a chance to implement today. Will update shortly.
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.
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/
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.
__imp_GetUserProfileDirectoryW
is https://learn.microsoft.com/en-us/windows/win32/api/userenv/nf-userenv-getuserprofiledirectoryw
aka "userenv"
Nice find! Guess we can take out the MinGW check but that might put us back to exactly #27.
Fixed.