Emscripten 1.38.17+ incompatible with upstream SDL 2.0.8

[Beuc]

I use recent upstream SDL2_* at https://play.freedink.org/ - with success so far.

Since c346176 precisely however, running the game issues:

missing function: emscripten_set_mousemove_callback

Somehow the .js file now declares:

function _emscripten_set_mousemove_callback(){err("missing function: emscripten_set_mousemove_callback");abort(-1)}

while it used to be:

function _emscripten_set_mousemove_callback(target,userData,useCapture,callbackfunc){JSEvents.registerMouseEventCallback(target,userData,useCapture,callbackfunc,8,"mousemove");return 0}

[kripken]

Hmm, looks like that was removed by #6202. That replaced those methods with _on_thread versions. There is a C header shim which makes the old form still work, but I suspect SDL2 calls it from JS, where there is no such shim?

@juj, was there a plan for backwards compatibility support for JS in such a case?

[Beuc]

SDL2 calls emscripten_set_mousemove_callback from C:

void
Emscripten_RegisterEventHandlers(SDL_WindowData *data)
{
    const char *keyElement;

    /* There is only one window and that window is the canvas */
    emscripten_set_mousemove_callback("#canvas", data, 0, Emscripten_HandleMouseMove);

With USE_SDL=2, this gets automagically replaced:

function _Emscripten_UnregisterEventHandlers($0) {
 $0 = $0|0;
 var $1 = 0, $2 = 0, $spec$store$select = 0, label = 0, sp = 0;
 sp = STACKTOP;
 (_emscripten_set_mousemove_callback_on_thread((30566|0),(0|0),0,(0|0),((2)|0))|0);
 (_emscripten_set_mousedown_callback_on_thread((30566|0),(0|0),0,(0|0),((2)|0))|0);

though I fail to understand where this is triggered.

With -lSDL2 we get:

function _Emscripten_RegisterEventHandlers($0) {
 $0 = $0|0;
 var $1 = 0, $2 = 0, $spec$store$select = 0, label = 0, sp = 0;
 sp = STACKTOP;
 (_emscripten_set_mousemove_callback((45958|0),($0|0),0,(370|0))|0);
 (_emscripten_set_mousedown_callback((45958|0),($0|0),0,(371|0))|0);

and no *_on_thread function is defined.

This is still the case in 1.38.20.
@juj ? :)

[Beuc]

OK, what I lacked was a complete recompilation of my dev root with all the .a libs.
(I had done that a few days before this last emscripten upgrade, that was too soon :))
(I'm surprised nothing biped during compilation though?)

[iceiix]

@Beuc I'm hitting this same "missing function: emscripten_set_mousemove_callback" error though in a different context, can you elaborate how it was resolved by "a complete recompilation of my dev root with all the .a libs"?

Trying to build the examples from https://github.com/tomaka/winit/ with emscripten, using emsdk 1.38.22, I had 1.37.12 installed previously but I've installed and reinstalled and activated the latest, still think I somehow have extra leftover state laying around. Is deleting ~/.emscripten_cache sufficient?

[juj]

The migration from emscripten_set_mousemove_callback() to emscripten_set_mousemove_callback_on_thread() is implemented via #defines in html5.h to keep source compatibility:

https://github.com/kripken/emscripten/blob/443447b14d34a3d710d33f229dea64e5c78a78ce/system/include/emscripten/html5.h#L483-L494

this is to avoid adding two redundant copies of each html5 function that would increase code size, and require compiler to perform the correct inlining choice to optimize the size down.

Try running emcc --clear-cache and emcc --clear-ports, and rebuild all code in your project. If there are old libraries left around that were compiled with older version of emscripten, then those might refer to the old symbol.

[iceiix]

Same result after clearing everything:

emcc --clear-cache
emcc --clear-ports
cargo clean

I also tried on a completely new system (a fresh virtual machine, clean OS install), cloned and installed emsdk 1.38.22, rustup with Rust stable, and winit from scratch, same "window.js:7196 missing function: emscripten_set_mousemove_callback".

If it helps, posted the window.js here: https://gist.github.com/iceiix/81accf2e1b2c62e24b8b27ca05d5398c

[juj]

Perhaps Rust installer stores precompiled libraries from and older Emscripten in its build distribution, that keep being out of date?

[iceiix]

Aha, that could be it. I updated to Rust stable 1.32.0 released today, and sure enough it downloads the standard library compiled for wasm32-unknown-emscripten:

info: installing component 'rust-std' for 'wasm32-unknown-emscripten'
info: installing component 'rust-std' for 'wasm32-unknown-unknown'

but I recompiled the example, with the same error. I'm not sure how/if I can update the emscripten for rust-std. rust-windowing/winit#760 any ideas?

(The alternative, for those who might find this issue in the future when trying to use Rust with WebAssembly, is to use the wasm32-unknown-unknown target instead, which compiles directly to wasm without emscripten.. but personally I would like to use the emscripten target if possible since it compiles my app almost untouched).

[iceiix]

Found out the reason for the Rust winit crate incompatibility. Unfortunately, winit uses FFI to access the emscripten C API, so although C source compatibility was maintained with #defines, it broke binary compatibility as accessed through Rust. Updating to the _on_thread functions fixed this particular issue, rust-windowing/winit#767