Validate all use cases and platforms

[ashtonmeuser]

As this project inches closer to stability, it'll be helpful to test on each platform and under each usage case. Formal tests are the ideal but at least this will serve as proof of things working at a given point in time. Should test with the Wasm Consume example project which uses most functionality of Godot Wasm.

I'll update the following as testing happens.

Use Case	Linux	macOS	Windows (MVSC)	Windows (MinGW)
GDNative addon	✅ 6db146b	✅ 29356da	✅ 29356da	🚫
GDExtension addon	✅ f2b1cc3	✅ 2999e89	✅ 2999e89	🚫
Godot 3 module	✅ eea765c	✅ 29356da	✅ 6db146b	❌ 2a56e2c
Godot 4 module	✅ f2b1cc3	✅ 2999e89	✅ f2b1cc3	❌ 6114faf

⏱️ Pending     ✅ Success     ❌ Failure     🚫 Unsupported

[fire]

What is blocking mingw validation?

[ashtonmeuser]

@fire Nothing besides my lack of time.

We need:

1. A new workflow similar to the other three that build the GDExtension/GDNative addon for Windows using MinGW. Note that this would be purely for peace of mind as it's not needed in the release artifact (we've got a Windows binary already via MVSC).
2. At least a point in time validation of Godot Wasm used as a module. Come to think of it, I'll take a look at your custom engine build which included MinGW if I'm not mistaken.

[ashtonmeuser]

There is no mention of MinGW or a use_mingw option in the Godot C++ bindings GDExtension Sconstruct (inherited by the Godot Wasm 4.x Sconstruct) or the GDNative Sconstruct files. Further, at the time of writing, there is no use_mingw option in the Godot Wasm 3.x Sconstruct (which does not inherit from Godot C++ bindings GDNative Sconstruct). All of this means that, henceforth, building the Godot Wasm GDExtension/GDNative addon with MinGW will not be supported.

[fire]

I will still attempt to build with mingw and send the results thought.

[ashtonmeuser]

That would be super helpful! I'd love to close this issue.

Cross compiling using MinGW on Linux fails with the following errors (truncated). Seems like more issues related to Windows SDK includes.

/usr/bin/x86_64-w64-mingw32-ld: modules/wasm/wasmer/lib/libwasmer.a(std-63790cb7e7741ec2.std.274b4a81-cgu.0.rcgu.o): in function `std::sys::windows::os::home_dir_crt::{{closure}}':
/rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\std\src\sys\windows/os.rs:298: undefined reference to `GetUserProfileDirectoryW'
/usr/bin/x86_64-w64-mingw32-ld: modules/wasm/wasmer/lib/libwasmer.a(std-63790cb7e7741ec2.std.274b4a81-cgu.0.rcgu.o): in function `std::sys::windows::net::Socket::shutdown':
/rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\std\src\sys\windows/net.rs:383: undefined reference to `shutdown'
/usr/bin/x86_64-w64-mingw32-ld: modules/wasm/wasmer/lib/libwasmer.a(std-63790cb7e7741ec2.std.274b4a81-cgu.0.rcgu.o): in function `std::sys_common::net::getsockopt':
/rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\std\src\sys_common/net.rs:82: undefined reference to `getsockopt'
/usr/bin/x86_64-w64-mingw32-ld: /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\std\src\sys_common/net.rs:82: undefined reference to `getsockopt'
/usr/bin/x86_64-w64-mingw32-ld: modules/wasm/wasmer/lib/libwasmer.a(std-63790cb7e7741ec2.std.274b4a81-cgu.0.rcgu.o): in function `std::sys_common::net::getsockopt':
/rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\std\src\sys_common/net.rs:82: undefined reference to `getsockopt'

[fire]

To be honest I wasn't debugging this because I wasn't sure if the Ref Githubissues.

Githubissues is a development platform for aggregating issues.