Emscripten CMake toolchain disables shared libraries

[jspanchu]

This is a bit confusing when there are ways to build shared libraries using -sSIDE_MODULE. Should the toolchain permit shared libs?

[jspanchu]

@kripken @sbc100

[mathstuf]

For easy reference for interested bystanders (like myself), the shared library docs: https://emscripten.org/docs/compiling/Dynamic-Linking.html#practical-details

[mathstuf]

See also: #16281 #17804

[sbc100]

For now I think this best to disable shared libraries where possible. SIDE_MODULE semantics and shared library semantics don't quite match up and the places where folks would normally want to use shared libraries probably don't make sense in emscripten in many cases. Emscripten users should always prefer static linking where possible.

[mathstuf]

FWIW, the issue we have is that we have a global object that gets copied into multiple targets and then different call stacks get different copies of the global. So an object might get some index A in its own TU and then gets passed to some code in another TU where the index A references something else in the other object. Since there are no shared libraries, I think we may be OK for now (though testing is needed).

[sbc100]

Can you explain what you mean by "global object" and "get some index A"? Index into what?

[mathstuf]

There is a static InternedStringStorage interned;-like object used for string interning. Objects intern strings and pass around handles/indices to the table when these handles are passed between code that each linked the static library containing interned, the tables may not agree with what has been interned to that point and the string returned from the table may differ (assuming it was even in-bounds). The proposed solution is to move it to a shared library so that it doesn't get copied into other libraries. This ran into problems with the Emscripten build because of this situation. But I think we can just ignore it since there will never be a shared library (until it is supported) and symbols won't get duplicated like they do in the standard builds.

FWIW, the duplicate symbols come through the Python module (which is shared so that it can be loaded by python) and an executable that also links to the code and then loads the Python support.

[sbc100]

Yes, if you use static linking, and the object file containing interned is part of several different static libraries then the linker will just pick the first one and ignore all the rest (assuming they all define the same set of global symbols).