Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
OpenFlipper-Free
OpenFlipper-Free
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 20
    • Issues 20
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 4
    • Merge Requests 4
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenFlipper-Free
  • OpenFlipper-FreeOpenFlipper-Free
  • Issues
  • #136

Closed
Open
Created Nov 08, 2017 by Martin Heistermann@mheistermannDeveloper

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 -fvisibility settings 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 ExportExternalSymbolsHint on 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?
Edited Nov 08, 2017 by Martin Heistermann
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None