Closed apollo13 closed 4 months ago
I'm curious, what version of emscripten did you use to build your binary? When I investigated a while ago, 1.38.43 was the last version that would work (but that's when used together with Rust, so it might play out differently when invoking emscripten directly).
[Edit:] Looking over it a bit, there's one function that's definitely a problem. But in any case, mupdf is a viewer, right? Iirc, wasmer's emscripten support doesn't allow for any graphics output. (Side note: You might have a better time trying to compile a non-js-targeting version with wasi-sdk.)
Hi @jcaesar, thank you for the kind reply. I used 3.1.18 and 3.1.11 iirc (certainly something newer than you used).
[Edit:] Looking over it a bit, there's one function that's definitely a problem.
Oh, makes sense, I'll remove it and see what that brings
EDIT:// not much, getTempRet0 is still in the imports.
But in any case, mupdf is a viewer, right? Iirc, wasmer's emscripten support doesn't allow for any graphics output.
First and foremost it is a library, you give it a bytestream with a pdf and get back a bytestream with a graphic, so I guess support for graphics output should be relatively irrelevant.
Side note: You might have a better time trying to compile a non-js-targeting version with wasi-sdk.
Good point, I'll clean up the wrapper as needed. That said I cannot use wasi-sdk because it does not support exceptions or setlongjmp and as such refuses to compile.
Emscripten support is not complete, and we're working on to define whether we will implement it or not. Emscripten imports have involved since it was last supported in wasmer, and we are not working on this at the moment.
Related but very old issue: https://github.com/wasmerio/wasmer/issues/577
I have a similar problems when trying to build a wasi compatible diff using emscripten. See https://github.com/Lessica/WasmGNUDiff/issues/1.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Feel free to reopen the issue if it has been closed by mistake.
Describe the bug
I am trying to execute a empscripten compiled binary and I am getting the following error:
not sure what the correct argument is to get the wasmer version but it is 3.0.0-beta
Steps to reproduce
Build a wasm project with
-s WASM -s STANDALONE_WASM -s PURE_WASI
to actually get a WASI (somewhat) binary. In my case I was compiling using the instructions here: https://github.com/ArtifexSoftware/mupdf/tree/master/platform/wasmRun the binary with wasmer and observe the above error.
Expected behavior
Wasmer should successfully execute the binary or provide a better error message (maybe even just a documentation update would help)
Additional context
Wasmer inspect shows:
I realize that wasmer might not detect this properly because the check for emscripten (at least if I am reading the code correctly in https://github.com/wasmerio/wasmer/blame/00c94019d746880daac2f92a2d198ee677ee1e14/lib/emscripten/src/utils.rs#L13-L27) only checks for imports called
_emscripten_memcpy_big
or__map_file
which do not seem to get used anymore. I tried to create a file including those imports, but failed to generate such a file (not sure if emscripten creates files with those at all nowadays).Please note that I am not saying that wasmer should support emscripten, but it would help users to get started if wasmer provided a better error.