Make embind work with -fvisibility=hidden #22095
Conversation
|
This looks to be sufficient for Qt's use case. More types can be exported if needed. There's a bit more to it: ideally embind should work with non-exported ("hidden") types as well, and it looks like C++ API like std::type_info::hash_code() and std::type_index may not work correctly for non-exported types. Looking at at system/lib/libcxx/include/typeinfo, there are two options from implementing typeinfo:
Emscripten currently uses the default option 1, but does not generate unique RTTI for non-exported types in libraries/side modules. |
msorvig
force-pushed
the
embind-visibility-hidden
branch
from
2969713
to
e053f23
Compare
|
@sbc100 Do you think there's some way we could properly have unique rtti for the program? |
msorvig
force-pushed
the
embind-visibility-hidden
branch
from
76f29df
to
e7062a7
Compare
|
Note previous discussion on #16711 |
Export emscripten::val and emscripten::memory_view in order to prevent embind errors: BindingError: _emval_take_value has unknown type N10emscripten11memory_viewIhEE Embind generates a numerical type id from the address of the std::type_info object resulting from evaluating a typeid expressiion (e.g. 'void *id = &typeid(T)'). However, C++ does not guarantee that this address is identical for all evaluations of the typeid expression. In practice it is when using static linking, but not when using dynamic linking when the libraries are built with the '-fvisibility=hidden' compiler option. The non-identical id's then cause embind to decide that types have not been registered when used from a library, since they have been registered with a different id by the main wasm module. Exporting the types in question makes typeid addresses identical again, and fixes/works around the issue.
msorvig
force-pushed
the
embind-visibility-hidden
branch
from
e7062a7
to
9391428
Compare
I think the way to achieve that is make sure the types are marked as This fix seems correct to me for the core embind types. They always want to be shared I think. We also have |
| self.set_setting('MAIN_MODULE', 1) | ||
|
|
||
| @requires_dylink | ||
| def test_embind_dylink_visibility_hidden(self): |
There was a problem hiding this comment.
This looks similar to what test_dylink_rtti is doing in test_core.py, but with some embind specifics. As such, perhaps it belongs alongside that test?
Rather than duplicating the three helper functions from test_core.py why not just put this test in test_core.py itself?
There was a problem hiding this comment.
It also might make more sense alongside test_embind_no_rtti
There was a problem hiding this comment.
Yes, tst_core could make sense as well (I had it there first). Is it primarily a dylink or embind test? test_embind_no_rtti sounds related, I'll check what that does.
(Note I have vacation time is coming up, so I'll get back to this in a couple of week's time.)
Export emscripten::val and emscripten::memory_view in order to prevent embind errors:
BindingError: _emval_take_value has unknown type N10emscripten11memory_viewIhEE
Embind generates a numerical type id from the address of the std::type_info object resulting from evaluating a typeid expressiion (e.g. 'void *id = &typeid(T)').
However, C++ does not guarantee that this address is identical for all evaluations of the typeid expression. In practice it is when using static linking, but not when using dynamic linking when the libraries are
built with the '-fvisibility=hidden' compiler option.
The non-identical id's then cause embind to decide that types have not been registered when used from a library, since they have been registered with a different id by the main wasm module.
Exporting the types in question makes typeid addresses identical again, and fixes/works around the issue.