SIDE_MODULE causes "imported function does not match the expected type"

[Andrea M]

Hi,

After days of hard work I finally worked out how to compile maplibre-native as a WASM side module, roughly 40MB (without optimisations). At the moment the file size doesn't worry me much.

maplibre-native is compiled using C++ 17 whereas my main module is compiled using C++ 23. Is this generally allowed? Might this be why I'm getting:

LinkError: WebAssembly.instantiate(): Import #7289 "env" "_ZNSt3__26chrono12steady_clock3nowEv": imported function does not match the expected type

Please note, I am using CMake.

# SIDE_MODULE

set(CMAKE_EXECUTABLE_SUFFIX ".wasm")

set_target_properties(mbgl-core PROPERTIES COMPILE_FLAGS "-O0 -pthread -fPIC --use-port=libpng --use-port=libjpeg --use-port=zlib --use-port=sqlite3 -s DISABLE_EXCEPTION_CATCHING=0 -DEMSCRIPTEN_HAS_UNBOUND_TYPE_NAMES=0 -DMLN_RENDER_BACKEND_OPENGL -DMLN_DRAWABLE_RENDERER")

set_target_properties(mbgl-core PROPERTIES LINK_FLAGS "--no-heap-copy -pthread  -fPIC --use-port=libpng --use-port=libjpeg --use-port=zlib --use-port=sqlite3 -O0 -lembind -lhtml5.js -lhtml5_webgl.js -lglfw.js -s ENVIRONMENT='web,worker' -s ALLOW_MEMORY_GROWTH=1 -s WASM=1 -s USE_GLFW=3 -s USE_WEBGPU=1 -s STANDALONE_WASM=1 -s ASSERTIONS=1 -s STACK_OVERFLOW_CHECK=2 -s MIN_WEBGL_VERSION=2 -s MAX_WEBGL_VERSION=2 -sFULL_ES3 -s EXPORT_ALL=1 -s DISABLE_EXCEPTION_CATCHING=0 -s SINGLE_FILE=0 -sSIDE_MODULE")

# MAIN MODULE

set_target_properties(reactDearImgui PROPERTIES COMPILE_FLAGS "-O3 -pthread -fPIC -Wno-error=deprecated-declarations -Wformat -s DISABLE_EXCEPTION_CATCHING=0 --use-port=libpng --use-port=sqlite3 --use-port=libjpeg --use-port=zlib")

set_target_properties(reactDearImgui PROPERTIES LINK_FLAGS "--no-heap-copy -pthread -fPIC --use-port=sqlite3 --use-port=libpng --use-port=libjpeg --use-port=zlib -O3 -lembind -lhtml5.js -lhtml5_webgl.js -lglfw.js -s DISABLE_EXCEPTION_CATCHING=0 -s ENVIRONMENT='web,worker' -s MODULARIZE=1 -s ALLOW_MEMORY_GROWTH=1 -s WASM=1 -s USE_GLFW=3 -s USE_WEBGPU=1 -s NO_EXIT_RUNTIME=0 -s STANDALONE_WASM=0 -s EXIT_RUNTIME=1 -s ASSERTIONS=1 -s STACK_OVERFLOW_CHECK=2 -s MIN_WEBGL_VERSION=2 -s MAX_WEBGL_VERSION=2 -sFULL_ES3 -s DISABLE_EXCEPTION_CATCHING=0 -s SINGLE_FILE=0 -sERROR_ON_UNDEFINED_SYMBOLS=0 -s EXPORT_ALL=1 -sMAIN_MODULE ${CMAKE_CURRENT_SOURCE_DIR}/deps/maplibre-native-fork/platform/emscripten/build/mbgl-core.wasm")

Any help with this would be greatly appreciated. I apologise in advance if the solution turns out to be trivial.

[Sam Clegg]

Hi Andrea, glad to hear you have things compiling at least.

A couple of pieces of advice to get started.

1.  If possible can you simply use static linking?   It would simplify things greatly and reduce code size.    Unless you program is very much based on around the idea of dlopen/dlsym I would strongly recommend avoiding dynamic linking.

2. If you must use `-sMAIN_MODULE` then I strongly recommend using `-sMAIN_MODULE=2`.  In this mode you pass your side module on the command line when linking the main module and emscripten can then figure out precisely what symbols it needs to include.

3. You don't need/want `-sSTANDALONE_WASM` when building your side module (in fact I think you probably don't need most of the link flags you have there).

If you do need dynamic linking and your problem persists then I suggest taking a look your main module and your side module using something like `wasm-objdump` to figure out what the signature of the `_ZNSt3__26chrono12steady_clock3nowEv` symbol on the import side (the side module) and the export side (the main module).

That symbol is `std::__2::chrono::steady_clock::now()` BTW.  It looks like its is always support to return a `class time_point` which itself  that simply contains a `calss duration`  which seems to be templatized so I suppose its size could vary?  I'm not sure yet, that could be the issue I suppose.  Again static linking is probably way to go.

cheers,

sam

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/aa75bf86-3c32-40d8-b059-8efc645ca96dn%40googlegroups.com.

[Andrea M]

Hi Sam,

Thanks for the prompt reply - on a Saturday on top of that.

To clarify, you mean I should use the -shared flag when building the side module?

Apologies for the dull question.

Best,

Andrea 

You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/TfGTVrHHAaw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28x5%2B98pqOGw4mOsAQvs5UCQdFdhbzya3qQ4sctUfr9_Q%40mail.gmail.com.

[Sam Clegg]

On Sat, Jun 29, 2024 at 3:08 PM 'Andrea M' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

Hi Sam,

Thanks for the prompt reply - on a Saturday on top of that.

To clarify, you mean I should use the -shared flag when building the side module?

No.  `-shared` doesn't build side modules today. 

My main advice is to avoid dynamic linking completely and use static linking.  i.e. use `.a` archives rather than a side module.

Failing that, use `-sMAIN_MODULE=2` which at least gives you dead code elimination.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2Bx6MRyHHJ0DsDKh%3DAsR5QN0MZFjAQB8ufBnSDUuEPtGuk0CTA%40mail.gmail.com.

[Andrea M]

Static linking appears to do the job!

Now I just need to rewrite/replace the bits that just won't work in emscripten, such as sched_setscheduler() and cURL.

I can't thank you enough.

Best,

Andrea