Cross-Plugin RTTI / dynamic_cast / OVM properties
On macOS, dynamic_cast between Plugins is broken, as typeinfo/RTTI is not shared between plugins.
This breaks OVM property lookup, e.g. the PropertyVisualizer cannot access OVM properties created in another plugin, but rather creates its own uninitialised properties with the same name, because the dynamic_cast on the correct property returns NULL, so it cannot be found. (Side note: maybe an optional request_property bool parameter like fail_if_missing would be useful?).
@lyon created a workaround for this by defining OVM_FORCE_STATIC_CAST, which will avoid the dynamic_cast, however this is at the cost of type safety and making it impossible to have multiple properties of different types sharing the same name.
I tried to fix this properly by setting a QPluginLoader option (ExportExternalSymbolsHint) that exports one plugin's symbols to the other plugins, cf https://www.graphics.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper/tree/fix_plugin_rtti_macos
This nicely fixed the issue on macOS, however I get immediate crashes on startup on Linux, I assume this is due to different things with the same symbol name in multiple Plugins that get mixed up.
Potential solutions:
- ExportExternalSymbolsHint + more appropriate
-fvisibilitysettings to avoid Linux issues (leveraging windows dllexport macros?) - Keeping RTTI info for all types that should be shared between Plugins in main OpenFlipper
- simple hand-rolled RTTI for OVM props to achieve better type safety, e.g. comparing type names from typeid().
- dirty fix: only enable
ExportExternalSymbolsHinton macOS
Open questions:
- Why does this even work on Linux & Windows? (EDIT: libstdc++ seems to use strcmp based type comparison, cf http://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html - libc++ does not and relies on the linker)
- Which symbol collisions cause the Linux crash?
- How is this done in OpenMesh?