Linking side modules and a main module

[John Dallman]

I am working on a mathematical modelling library and its test harness, both of which are compiled from C and C++ code. The usual way to link them is as two shared libraries, both fully internally resolved, and a small executable which just contains main() and calls them. The test harness has lots of calls to the library, of course. 

I can link the libraries as side modules with .so file extensions. I'd rather they were .wasm files, but I can live with what I have. The main library is libpskernel.so, and the test harness code is libkid_support.so. The latter needs to call the former directly, without a JS layer.

When I link the executable, supplying the names of the .so files on the link line, I get this error:

/u/jgd/regimes/webasm/libkid_support.so: shared library dependency not found in library path: `libpskernel.so`. (library path: ['/sdl/prairie/tools/kernel_tools/webasm/emscripten/v6.0.4/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/pic', '/sdl/prairie/tools/kernel_tools/webasm/emscripten/v6.0.4/emsdk/upstream/emscripten/src/lib'] 

The first element of the library path contains crtbegin-mt.o; the second contains a lot of .js libraries. How do I add directories to the library path in question? 

I'm currently using Emscripten 6.0.4; do I need a later version?    

Thanks in advance. 

John

[John Dallman]

> I'm currently using Emscripten 6.0.4; do I need a later version?    

Emscripten 6.0.10 does not help. 

[Sam Clegg]

This error is coming form the static linker.  It needs to be able to find the full set of transitive shared library dependecies.

In this case I assume you are somehow linking against `libkid_support.so` but not directly against `libpskernel.so`.   Can you share the full link command perhaps so we can see what is going on?

The library path in question is just the library uses by the linker, so you can add paths to using `-L`.  For example, it looks like you maybe need `-L/u/jgd/regimes/webasm/` ?  

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 visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqg%3DEUj_57s_aUBVK%3D2ciGocBZZHHzhTBBqF2Z1%3DO%2BCtPEg%40mail.gmail.com.

[John Dallman]

> The library path in question is just the library uses by the linker, so you can add paths 

> to using `-L`.  For example, it looks like you maybe need `-L/u/jgd/regimes/webasm/` ?  

Aha! adding `-L/u/jgd/regimes/webasm/` gets me past that to a different error:

em++: warning: dynamic linking + pthreads is experimental [-Wexperimental]

error: undefined symbol: _emscripten_run_callback_on_thread (referenced by $JSEvents, referenced by root reference (e.g. compiled C/C++ code))
warning: To disable errors for undefined symbols use `-sERROR_ON_UNDEFINED_SYMBOLS=0`
warning: __emscripten_run_callback_on_thread may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors
    at finalCombiner (file:///sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/src/jsifier.mjs:968:13)
    at Module.runJSify (file:///sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/src/jsifier.mjs:1005:5)
    at file:///sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/tools/compiler.mjs:100:17

I'll try adding _emscripten_run_callback_on_thread to EXPORTED_FUNCTIONS. 

Thanks,

John

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_4L%2BNKzTdK3Ha8BhByu8fKxD10rW%2Bf7o_hxZ%2BVosPVCw%40mail.gmail.com.

[John Dallman]

> I'll try adding _emscripten_run_callback_on_thread to EXPORTED_FUNCTIONS. 

Well, that didn't work. Here's the full link line:

em++ -pthread --target=wasm32 -pthread --target=wasm32 -fexceptions --emit-symbol-map -sNO_DISABLE_EXCEPTION_CATCHING -sSTRICT=1 -sSUPPORT_LONGJMP=1 -sGROWABLE_ARRAYBUFFERS=2 -sEMULATE_FUNCTION_POINTER_CASTS=1 -sBINARYEN_EXTRA_PASSES=--pass-arg=max-func-params@55 -fPIC --pre-js /Parasolid/lx86/tools/patssy/com/kid_node_prerun.js -sINITIAL_MEMORY=3GB -sMAXIMUM_MEMORY=4GB -sALLOW_MEMORY_GROWTH -sSTACK_SIZE=16MB -sDEFAULT_PTHREAD_STACK_SIZE=2MB -sEXPORTED_FUNCTIONS=ENV,_main,__emscripten_run_callback_on_thread -sINCOMING_MODULE_JS_API=preRun -sEXIT_RUNTIME=1 -sNODERAWFS -sMAIN_MODULE=1 -L/u/jgd/regimes/webasm -sASSERTIONS=1 -sSAFE_HEAP=0 /Parasolid/lx86/v390_webasm/lsp/kernel.o /shamrock/sw_tools/lib/webasm/aga_fix.o /u/jgd/regimes/webasm/libkid_support.so /u/jgd/regimes/webasm/libpskernel.so -o kid.out

em++: warning: dynamic linking + pthreads is experimental [-Wexperimental]
error: undefined symbol: _emscripten_run_callback_on_thread (referenced by $JSEvents, referenced by root reference (e.g. compiled C/C++ code))
warning: To disable errors for undefined symbols use `-sERROR_ON_UNDEFINED_SYMBOLS=0`
warning: __emscripten_run_callback_on_thread may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors
    at finalCombiner (file:///sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/src/jsifier.mjs:968:13)
    at Module.runJSify (file:///sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/src/jsifier.mjs:1005:5)
    at file:///sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/tools/compiler.mjs:100:17

em++: error: '/sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/node/24.19.0_64bit/bin/node /sdl/prairie/tools/kernel_tools/webasm/emscripten/lx86/v6.0.10/emsdk/upstream/emscripten/tools/compiler.mjs -' failed (returned 1)
Warning: Error building kid.out

 

Thanks, 

John

[Sam Clegg]

The `_emscripten_run_callback_on_thread` function is part of the libhtml5.a native library, but when you build with -sSTRICT this does not get included by default.    Perhaps it should because libhtml.js is still included by default.   This certainly points to an inconsistency that should probably be fixed.

I imagine that you can fix by adding `-lhtml5` or removing `-sSTRICT`?

cheers,

sam

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqg%3D%2Bf6OCgk--_OXDBraL6oKbj5DdOeU0Nvsvph5aiTXeuQ%40mail.gmail.com.

[Sam Clegg]

I tracked down the root cause and fixed it here: https://github.com/emscripten-core/emscripten/pull/27799

[John Dallman]

Thanks very much. Using -lhtml5 gets me linking for now: will the fix be in 6.0.11? 

However, I get function signature mismatches when I try to run this assemblage: the code works happily when it is all linked statically, but not like this. The error I get is, with the symbols pasted in: 

RuntimeError: function signature mismatch
    at wasm://wasm/00657fd2:wasm-function[5935]:0x12e6f9

        kid.out.symbols:5935:dynCall_vi
        libkid_support.so.symbols:5935:lsp_select

    at invoke_vi (/sdl/prairie/users/jgd/regimes/webasm/kid.js:44634:19)
    at wasm://wasm/015a886e:wasm-function[5830]:0x4d830e

        kid.out.symbols:5830:(anonymous namespace)::fallback_free(void*)
        libkid_support.so.symbols:5830:interpret

    at wasm://wasm/015a886e:wasm-function[5941]:0x4ed98d

        kid.out.symbols:5941:dynCall_iii

    at _LSP_kid_main (/sdl/prairie/users/jgd/regimes/webasm/kid.js:6880:37)
    at wasm://wasm/00657fd2:wasm-function[203]:0x50277                      
   
        kid.out.symbols:203:main
        libkid_support.so.symbols:203:CRSOFA

    at callMain (/sdl/prairie/users/jgd/regimes/webasm/kid.js:45361:15)
    at run (/sdl/prairie/users/jgd/regimes/webasm/kid.js:45399:22)
    at /sdl/prairie/users/jgd/regimes/webasm/kid.js:45410:27

 

The duplication of symbol numbers has me wondering if the wrong function might be being called, causing the signature mismatch. Is this possible? If so, is there a way arround it?   

Thanks,

John

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29SbnyF6SkCkXr%2Bh1XAFgV7qABPUDje3nmBLgu4KhOPDA%40mail.gmail.com.

[John Dallman]

Sorry, forgot to say that both the .so files and the executable are linked with -sEMULATE_FUNCTION_POINTER_CASTS=1. 

[John Dallman]

Oh, rats! I'd failed to notice that SIDE_MODULE and MAIN_MODULE are both applicable at compile time as well as link time. I'll fix that first.