Add WASM_BIGINT linker flag to the web build
#88594
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adamscott
added
cherrypick:4.1
akien-mga
approved these changes
Feb 20, 2024
akien-mga
added
cherrypick:3.x
|
Thanks! |
|
Hi! Sorry for invasion but can someone help me to implement this fix? I use 4.3 dev3 version and I have the same issue when I try to run a game on CrazyGames. Is there a build with the fix or how can I modify my local version of Godot 4.3 dev3? Will be very grateful for just pointing me out 🙏 |
|
@flashag You will need to build your own export templates with the changes from this PR, or with Emscripten < 3.1.41. |
github-actions bot
pushed a commit
to luismedel/st-puzzles-macos
that referenced
this pull request
Mar 1, 2024
I updated Emscripten recently, to version 3.1.54. The result was that none of the WASM puzzles run any more, because they produce a stack trace at startup with the error message "to do setValue(i64) use WASM_BIGINT". I don't fully understand this. The stack trace comes via a JS wrapper around a WASM-compiled function called __main_argc_argv, which sounds like something in the Emscripten library startup. Somewhere in there it goes via _js_get_date_64(), which tries to write an i64 into the WASM memory array, which hits this abort in setValue(). Web searching for the error message turned up godotengine/godot#88594 which gave me the clue that '-s WASM_BIGINT' is a command-line setting for the Emscripten linker. And indeed, setting that makes the startup-time error go away and the puzzles run again. But it also causes older versions of all browsers to be unsupported, presumably on the grounds that they don't have whatever WASM bigint feature this flag causes the code to use. I don't really understand what's going on here. I assume _js_get_date_64 is being called to handle a 64-bit time_t. But the Puzzles code doesn't work with time_t at all, so this is entirely in the Emscripten standard library. And if the pre-main() startup code needs a 64-bit integer write, which won't work without this flag, then surely _nothing_ would work without this flag, and surely someone would have noticed that, and made that flag the default? This all seems confusing and I wonder if I've misunderstood something. However, if I don't fix it in _some_ way, the web puzzles will stay out of action for days and I'll get lots of email complaints. So here's something that makes them basically work again, and maybe we can figure out the rest of the story later.
|
Cherry-picked for 4.2.2. |
akien-mga
removed
cherrypick:4.1
|
Cherry-picked for 3.6. |
akien-mga
removed
cherrypick:3.x
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds the
WASM_BIGINTlinker flag to the web build in order to fix issues withi64values. This fix is needed to call Javascript from Godot since emscripten version 3.1.41.Fixes #88249