Linking missing system libraries for side module

[fibbo]

Reading section System Libraries it is written that in order to link system library calls needed by the side module one can either build the main module with EMCC_FORCE_STDLIBS=1 set as environment variable and link all, or build the side module with -v to see which libraries are actually needed.

The function in the side module:

double* new_double(int size)
{
  double* d = new double(size);
  for (int i = 0; i<size; i++)
  {
    d[i] = i;
  }
  return d;
}

Now:

• Using -v doesn't tell me anything and so I cannot specifically link system libraries
  Output of -v:

shared:INFO: (Emscripten: Running sanity checks)
"E:/emsdk-master/clang/e1.38.28_64bit\opt.exe" C:\Users\pgl\AppData\Local\Temp\emscripten_temp_4frnb_\module.bc -strip-debug -disable-verify -globaldce -disable-loop-vectorization -disable-slp-vectorization -vectorize-loops=false -vectorize-slp=false -o C:\Users\pgl\AppData\Local\Temp\emscripten_temp_4frnb_\module.bc

• EMCC_FORCE_STDLIBS=1 also doesn't work

The error I get is:

Assertion failed: missing linked function __Znwm. perhaps a side module was not linked in? if this function was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment

If I export __Znwm manually with -s EXPORTED_FUNCTIONS="['__Znwm']" in the main module, then it works. The other option is to use -s EXPORT_ALL=1 in the main module, but this results in a massive main module (1.8mb js file and 1mb wasm).

Am I missing something?

[sbc100]

Your experience describes the status quo. I think most people use -s EXPORT_ALL=1 when building the main module. Either that or maintain a very long EXPORTED_FUNCTIONS list. If you don't do this the symbols you need will be GC when building the main module.

We could write some kind of helper script that uses information from the SIDE_MODULE(s) to generate an EXPORTED_FUNCTIONS list, but that doesn't exist today.

[sbc100]

In other words I don't think this is a bug, but I suppose it could be re-phrases as a feature request?

[fibbo]

This very long list of EXPORTED_FUNCTIONS: these are the mangled names I assume? Do I find this out by trial and error?

Also I don't fully understand the documentation then. What's the point of EMCC_FORCE_STDLIBS? And why is -v not showing any include lib[...] as mentioned in the docs? Has that changed?

[sbc100]

One way to create your EXPORTED_FUNCTION list would be to inspect your wasm side module with wasm-dis to wasm-objdump and find all its imports.

EMCC_FORCE_STDLIBS=1 is working for me. It means that all the stdlibs are included in your main module. I believe you still need -s EXPORT_ALL=1 in order to have the symbols in these libraries preserved and exported.

It looks like there is bug in the documentation regarding the use of -v. I believe the what they meant was EMCC_DEBUG=1 in the environment. However, we could change it so that -v does this. The relevant line is tools/system_libs.py:710.

[sbc100]

I proposed a change to fix the -v issue: #8310

It happened to speed up the tests too! :)

[fibbo]

I see. Regarding -v or EMCC_DEBUG=1 I guess either one is fine as long as the documentation is mentioning the right one :)

One last question when using
-s EXPORT_ALL=1 the file sizes for the js and wasm increase by quite a bit. Using EMCC_FORCE_STDLIBS doesn't add much - what does EXPORT_ALL actually export that makes the files so much bigger?

And thanks for the PR! Will maybe make someones live easier in the future.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[liquidaty]

documentation still says -v which does not print out include lib[...] results. why is it marked wontfix for something so simple and proper as fixing inaccurate documentation?

[sbc100]

These days we have the ability to simply pass the names of the side module when linking the main module and everything should be taken care of automatically. So only users who don't have the side modules available at when they link the main module need to worry about this issue.

I will update the docs and remove the mention -v which doesn't work.

[aisnote]

hi, I meet kind of this issue too. below is my scenario:

• main module -> load side module with dlopen.
  • sModule = dlopen(side_module); // ok
    sFunctionPtr = dlsym(sModule, "sFunction "); // ok
    sFunctionPtr address is ok.
    But later sFunction will be not referenced as below inside the browser.

Aborted(Assertion failed: undefined symbol sFunction. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)

Any idea? thanks.