Linking entire libstdc++ to a SIDE_MODULE

[tdrz]

I'm looking into building PostGIS for PGlite (PostgreSQL in WASM) - more here. This is a C++ extension, the first of the kind that PGlite would support.

I want to know if it is possible to statically link libstdc++ to it such that we wouldn't have to link libstdc++ to PGlite itself. This is in order to save space for everyone who's not interested in this extension. Something like -Wl,--whole-archive -lstdc++ -Wl,--no-whole-archive?

I have tried it (with emsdk v3.1.74) but at runtime I was getting crashes related to missing symbols (I manually added some of them to EXPORTED_FUNCTIONS in the MAIN_MODULE to see if that makes it run further, which it did).

[sbc100]

I'm not sure that would work since then you might end up with two different copies of libstdc++ symbols in a program. One copy in your side module and another copy in the main module. In theory these symbols should be global, so only the first one that is loaded should take effect, but in practice I imagine this could be painful.

If you do want to go ahead with it then -Wl,--whole-archive -lstdc++ does sounds like the correct approach. What symbols were missing?

[tdrz]

RuntimeError: Aborted(Assertion failed: undefined symbol '_ZNSt12length_errorD1Ev'. 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)
$ c++filt _ZNSt12length_errorD1Ev
std::length_error::~length_error()

I'm not sure that would work since then you might end up with two different copies of libstdc++ symbols in a program.

For now, I only want a single libstdc++ copy - the one linked to the SIDE_MODULE. The MAIN_MODULE is C, so I guess it only links against libc?

[sbc100]

For now, I only want a single libstdc++ copy - the one linked to the SIDE_MODULE. The MAIN_MODULE is C, so I guess it only links against libc?

But doesn't that mean that your users cannot write their main module in C++? Or cannot use other extensions that are also C++?

[pmp-p]

I think in that particular case the linking of c++ extensions would be exactly the same as Panda3D C++ module loading into python-wasm ( C only ). This is known to work for all emscripten versions.

So i suspect the problem is not in emscripten, but in postgis linking of a fully static library which should bring the c++ stdlib. Postgres extensions links to shared by default, not static ...

[tdrz]

But doesn't that mean that your users cannot write their main module in C++? Or cannot use other extensions that are also C++?

This would be a build of PostGIS as a side module for PGlite. No other uses are intended, but others are free to modify both as they want.

[tdrz]

So i suspect the problem is not in emscripten, but in postgis linking of a fully static library which should bring the c++ stdlib. Postgres extensions links to shared by default, not static ...

IIUC, symbols such as _ZNSt12length_errorD1Ev are only defined in /emsdk/upstream/lib/libc++.a so a static library.

[tdrz]

@sbc100

I am looking to understand more about emscripten's linking process. If I add symbols like _ZNSt12length_errorD1Ev to EXPORTED_FUNCTIONS when building the main module, the execution runs further. To me, this means that libstdc++ is actually linked to the main module, not to the side module, although I only added -lstdc++ when building the side module...

[sbc100]

Yes, normally -lstdc++ gets linked into the main module. I would hope that -Wl,--whole-archive -lstdc++ causes it to be linked into the side module, but clearly its not working as intended.