ROS2 plugin does not load for clang-tidy
I have a MoveIt2 PR that creates a new plugin. It's working great except CI does not pass for galactic. Strangely, CI does pass for galactic-testing and rolling.
It looks like there have not been any commits to the pluginlib repo in 9 months so I think galactic and galactic-testing should be the same.
Here's a link to my PR. The terminal printout when CI fails is:
Error: mponent_container_mt-2] [ERROR] [1634151469.735356961] [moveit_servo.servo_calcs]: Exception while loading the smoothing plugin 'online_signal_smoothing::ButterworthFilterPlugin': 'MultiLibraryClassLoader: Could not create object of class type online_signal_smoothing::ButterworthFilterPlugin as no factory exists for it. Make sure that the library exists and was explicitly loaded through MultiLibraryClassLoader::loadLibrary()' Error: ROR] [component_container_mt-2]: process has died [pid 16245, exit code 1, cmd '/opt/ros/galactic/lib/rclcpp_components/component_container_mt --ros-args -r __node:=servo_container -r __ns:=/'].
One maybe-unusual thing is that I created a plugin within the same package as the base class. I think the base class and the actual plugins are usually in different packages.
galactic-testingis a MoveIt specific "thing" AFAICT (here, a Docker image name, hosted atghcr.io/ros-planning/moveit2). It's not a branch ofpluginlib, nor is there a ROS 2 package repository which has agalactic-testingversion.The way you refer to it in your question implies you are under the impression it is something part of the regular ROS 2 repositories / distribution channels.
Could you clarify?
I'm sure you're probably right. So the question boils down to, why does the
galacticdocker image cause issues butgalactic-testingdoes not...Maybe it's due to this
clang-tidy: pedantic?Seeing as it's so MoveIt specific, should you not ask the people who set this up?
galactic-testingis simply using a docker image that uses theros2-testingrepository forgalactic. Since the build works just fine withoutclang_tidy: pedantic, I'm pretty sure it's an issue with the plugin configuration and clang. There are plenty of other plugins in MoveIt that work just fine with clang, though. My thought is that the plugin base itself doesn't have a library target that is separate from the plugin. It's only provided with a simple header file. Since the base class is purely abstract, clang will only create a vtable in the plugin translation unit. The classloader has no way to access the vtable of the plugin base before loading the plugin itself. I wonder if pure virtual plugin base classes are even really supported of if they should be inline or at least need some default constructors/destructors.They are making some suggestions. Removing
CLANG_TIDY: pedanticdoes fix it. I'll try a better way.