Web export with gdextension not working on 4.3 if threads/nothreads variants are mismatched

[cosformula]

Tested versions

• Reproducible on 4.3.dev6 ~ 4.3.beta3
• Not Reproducible on 4.2.2 stable

System information

Confirmed on MacOS and Windows

Issue description

Web export with gdextension not working on 4.3 dev6 ~ 4.3.beta3.
Empty project with gdextension support flag on works well, but add a gdextention (I use debug draw 3d, but my own gdextention not working too) addon to the project cause problem, and console says:

LinkError: WebAssembly.instantiate(): Import #62 "env" "memory": mismatch in shared state of memory, declared = 1, imported = 0

Steps to reproduce

Download MRP, run in broswer.

Minimal reproduction project (MRP)

gdextention test.zip

[akien-mga]

Which Emscripten version did you use to compile the GDExtension?

[cosformula]

Which Emscripten version did you use to compile the GDExtension?您使用哪个 Emscripten 版本来编译 GDExtension？

I use 3.1.62.

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.62-git
clang version 19.0.0git
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/emscripten/3.1.62/libexec/llvm/bin

[akien-mga]

I can reproduce the issue with the MRP on Firefox with 4.3.beta3, with these errors:

Uncaught (in promise) LinkError: imported function 'env._ZNSt3__26chrono12steady_clock3nowEv' signature mismatch
still waiting on run dependencies: [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
dependency: loadDylibs [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
(end of list) [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
still waiting on run dependencies: [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
dependency: loadDylibs [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
(end of list) [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
still waiting on run dependencies: [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
dependency: loadDylibs [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
(end of list) [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
still waiting on run dependencies: [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
dependency: loadDylibs [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)
(end of list)

Worth noting that the addons includes prebuilt binaries in the git repo. If you're using those instead of compiling your own, then they might not have been compiled with Emscripten 3.1.62, but instead with whichever version @DmitriySalnikov used for the 1.4.2 release. I tested updating to 1.4.3 and it still has the same issue.

One should test with a custom built extension using Emscripten 3.1.62 (like 4.3.beta3) or 3.1.63 (regression fix release, which we'll use for 4.3.rc1).

[DmitriySalnikov]

but instead with whichever version @DmitriySalnikov used for the 1.4.2 release

3.1.39 as mentioned here.

And I finally found what the problem was!
I even managed to launch the project in Firefox. (thanks to the emscripten update?)

LinkError: WebAssembly.instantiate(): Import #62 "env" "memory": mismatch in shared state of memory, declared = 1, imported = 0

The mismatch between shared and non-shared memory directly depends on threads support.

I can reproduce the issue with the MRP on Firefox with 4.3.beta3, with these errors:

Uncaught (in promise) LinkError: imported function 'env._ZNSt3__26chrono12steady_clock3nowEv' signature mismatch
still waiting on run dependencies: [tmp_js_export.js:46811:18](http://localhost:8060/tmp_js_export.js)

Yes, for some reason it is not possible to use std::chrono in my module and I had to switch to using Time::. I have not been able to solve this problem yet.
It seems that the standard libraries are not included in the SIDE_MODULE.

Here you can download .gdextension_libs with new libraries. And here Is an updated .gdextension.
These libraries should still be supported starting with godot 4.2.

[cosformula]

Thanks to @DmitriySalnikov. On 4.3.beta3, I'm able to fixed this issue by building gdextensions using threads=no|yes and edit the .gdextension file like below:

...
web.wasm32.nothreads = "res://addons/xxx/bin/libxxx.web.template_debug.wasm32.nothreads.wasm"
web.wasm32 = "res://addons/xr/bin/libxxx.web.template_debug.wasm32.wasm"
...

Maybe we should add this sections to the gdextension tutorial?

[GeTechG]

I got a similar problem with the same message when running on android, but I was using the official build without multithreading and gdextension.

[Nihlus]

@DmitriySalnikov Did you ever figure out the issue with using Chrono? I'm seeing the same problem along with a mismatched signature on env.strtoll, which is blocking my extension from working with web exports at the moment. I've built with emscripten 3.1.64 to match Godot, but it doesn't appear to make a difference.

[DmitriySalnikov]

@DmitriySalnikov Did you ever figure out the issue with using Chrono?

I tried a few more times, but couldn't solve the problem. So the easiest way is to start using the Godot API.
Perhaps someone with more experience with emscripten can tell us.

[Nihlus]

I did that with Chrono, yeah, but the `strtoll` usage is deep in a dependency that I can't easily touch - wouldn't even know what to replace it with either :( I might make a separate issue for these issues to get better visibility on it.

…

On Mon, 2 Sept 2024, 00:13 Дмитрий Сальников, ***@***.***> wrote: @DmitriySalnikov <https://github.com/DmitriySalnikov> Did you ever figure out the issue with using Chrono? I tried a few more times, but couldn't solve the problem. So the easiest way is to start using the Godot API. Perhaps someone with more experience with emscripten can tell us. — Reply to this email directly, view it on GitHub <#94537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR3MTA2F4AJ2YVPSOYXX63ZUOGPLAVCNFSM6AAAAABLERHHH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRTGUYTKMRQGU> . You are receiving this because you commented.Message ID: ***@***.***>