simon-git: puzzles (main): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Fri Mar 1 12:32:17 GMT 2024


TL;DR:
  cc91f8b Emergency fix to Puzzles WASM builds.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2024-03-01 12:32:17

commit cc91f8b9deafbf284609e3511ff900104499da9c
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=cc91f8b9deafbf284609e3511ff900104499da9c;hp=e20644a3baa70dfd5baf790047ce821b396df312
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Mar 1 12:24:05 2024 +0000

    Emergency fix to Puzzles WASM builds.
    
    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
    https://github.com/godotengine/godot/pull/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.

 cmake/platforms/emscripten.cmake | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)



More information about the tartarus-commits mailing list