You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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.
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).
Activity
jspanchu commentedon Sep 26, 2023
@kripken @sbc100
mathstuf commentedon Sep 26, 2023
For easy reference for interested bystanders (like myself), the shared library docs: https://emscripten.org/docs/compiling/Dynamic-Linking.html#practical-details
mathstuf commentedon Sep 26, 2023
See also: #16281 #17804
sbc100 commentedon Sep 26, 2023
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 commentedon Sep 26, 2023
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 commentedon Sep 26, 2023
Can you explain what you mean by "global object" and "get some index A"? Index into what?
mathstuf commentedon Sep 26, 2023
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 containinginterned, 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 commentedon Sep 26, 2023
Yes, if you use static linking, and the object file containing
internedis 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).