Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to load GDExtension in Web export due to LinkError with env.strtoll #96492

Closed
Nihlus opened this issue Sep 2, 2024 · 3 comments · Fixed by godotengine/godot-cpp#1603
Closed

Comments

@Nihlus
Copy link

Nihlus commented Sep 2, 2024

Tested versions

  • Reproducible in 4.3.stable.official.77dcf97d8

System information

Godot v4.3.stable - Linux Mint 22 (Wilma) - X11 - Vulkan (Forward+) - dedicated Radeon RX Vega (RADV VEGA10) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)

Issue description

I have a GDExtension project that statically links with a relatively large speech recognition library. It works fine on desktop platforms but fails to load in Web exports, showing a LinkError from the WASM runtime.

Uncaught (in promise) LinkError: imported function 'env.strtoll' signature mismatch 

This issue also presents when using symbols from std::chrono in the extension, even though none of them are exported or made available to other modules. The problem is described in #94537 (comment), and I am experiencing more or less the same thing.

Steps to reproduce

  1. Extract MRP
  2. Clone godot-cpp into the extracted folder using the 4.3 branch
  3. build with scons
  4. export a web version of the project
  5. run it
  6. observe error in dev console

Minimal reproduction project (MRP)

minimal-repro.zip

If you want to test the full project or the MRP does not work for whatever reason, the full source code is available at https://github.com/Nihlus/gdvosk. Binaries can be downloaded from the workflows as artifacts. I had some trouble running the MRP due to what appears to be another Godot bug regarding stack smashing on my system, so YMMV.

@Nihlus
Copy link
Author

Nihlus commented Sep 3, 2024

I believe I found the problem - there's a compilation flag mismatch between godot-cpp and godot proper, meaning that -sWASM_BIGINT is not present (among a number of other flags). This flag changes the representation of 64-bit integers in the compiled code, resulting in types like long long having different signatures between the builds.

The solution is to add this flag to the compilation, but there should probably be a review of the rest of the flags as well. There's also some discrepancies when using the CMake support in godot-cpp, but that's probably better as a separate issue.

@DmitriySalnikov
Copy link
Contributor

It seems that chrono also works without problems with WASM_BIGINT.

@Faless
Copy link
Collaborator

Faless commented Sep 4, 2024

Thank you for looking into this, we forgot to add WASM_BIGINT to the godot-cpp build when we added it to godot in #88594 .

Should be fixed once godotengine/godot-cpp#1566 is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment