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

Emscripten 1.38.17+ incompatible with upstream SDL 2.0.8 #7525

Closed
Beuc opened this issue Nov 17, 2018 · 9 comments

Comments

Projects
None yet
4 participants
@Beuc
Copy link
Contributor

commented Nov 17, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 24, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 24, 2018

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

This comment has been minimized.

Copy link

commented Jan 14, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2019

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

This comment has been minimized.

Copy link

commented Jan 15, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 15, 2019

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

@iceiix

This comment has been minimized.

Copy link

commented Jan 18, 2019

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

This comment has been minimized.

Copy link

commented Jan 20, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.