Replace ign common plugin loader with ign-plugin

[ahcorde]

This PR is related with this issue #18

I have some issue. When I run the tests for ign-sensors4 everything look good. Then problem is inside ign-gazebo code, when the library is loaded for some plugins is not able to find the pluginNames.

For example:

• Camera

  • In the test: LoadLib() returns that the loaded plugin is N8ignition7sensors2v416SensorTypePluginINS1_12CameraSensorEEE -> ignition::sensors::v4::SensorTypePluginignition::sensors::v4::CameraSensor
  • Inside ign-gazebo code: the LoadLib() returns a empty structure. (No loaded plugins)

• Depth Camera or GPU lidar are working properly.

Maybe @mxgrey or @scpeters can add some light here.

Signed-off-by: ahcorde ahcorde@gmail.com

[mxgrey]

Off the top of my head, I can't think of why no plugins are showing up for ign-gazebo, but I would guess maybe something funny is going on with the linker. Does the problem occur on all platforms (Linux, Mac, Windows)?

[ahcorde]

I try to explain what I think it's happening here:

• ign-gazebo is linking against camera from ign-sensor in the Sensor.cc. This is the CMakeLists.txt. When the program starts then the symbols from libignition-gazebo4-sensors-system.so are loaded which also includes libignition-sensors4-camera.so because as I explained before the CMake is linking with the sensor library.

• This same file (Sensor.cc) is loading the camera plugin (libignition-sensors4-camera.so) using dlsym, In this line of code if there is a <sensor name="camera" type="camera"> in the sdf file. Here is where the problem arises

The Macro IGN_SENSORS_REGISTER_SENSOR(CameraSensor) is creating a struct in an anonymous namespace. Inside this namespace a static variable is created which is in charge of loading the symbols. The first time that this struct is generated is when the class is called (linked by the CMake) but the second time that we need to read the symbols (in the "createSensor" method) then this static variable is no being initialized again.

I have create a simple demo to reproduce this here.

The right example to hace a look is ./main_dl_link_cmake. This is doing exactely the same thing.

The hello library contains a struct and a static variable inside an anonymous namespace. In the main this library is linked with cmake and then is being loaded using dlsym(). The text is only printed once and it should be printed twice

[ahcorde]

I think I found a solution. If the symbols are already loaded, why we need to reload it again? There is no need to do it.

I added in the Manager class a method called AddSensor() 25be8d7 to add a sensor to the list of loaded sensors.

The I will use this class in ign-gazebo. Here it's the PR using this new method. gazebosim/gz-sim#304

[ahcorde]

waiting this PR #46 that fix the Github actions

[chapulina]

It looks like plugins are not being loaded correctly on CI

[chapulina]

Is this include needed at every sensor? Shouldn't SensorFactory.hh be enough?

[ahcorde]

According with the migration guide https://github.com/ignitionrobotics/ign-plugin/blob/94482af3e9b2cc1cbb7c2dbeb2c7846f8283f0f6/MIGRATION.md#registering-a-plugin

I added this header for registering plugins. All sensors are individual components that why I need to use ignition/plugin/Register.hh in the cc file. I tried to include this header (or #include <ignition/plugin/RegisterMore.hh>) in the SensorFactory.hh but I was not able to compile the code because an undefined reference:

``/usr/bin/ld: ../lib/libignition-sensors4-imu.so.4.0.0~pre1: undefined reference `IgnitionPluginHook'

[chapulina]

According with the migration guide

I see. I mean, we'd still be including that header, just indirectly. The way ign-sensors is exposing the plugin functionality is through SensorFactory. So technically each sensor doesn't need to know about ign-plugins, they just know they need to use the IGN_SENSORS_REGISTER_SENSOR macro from the SensorFactory.hh header.

I tried to include this header (or #include <ignition/plugin/RegisterMore.hh>) in the SensorFactory.hh but I was not able to compile the code because an undefined reference:

SensorFactory.hh uses the IGNITION_ADD_PLUGIN macro from ignition/plugin/Register.hh, so I believe it should include that header. Otherwise, that header is not usable on its own.

And it probably needs to link against ignition-plugin${IGN_PLUGIN_VER}::register to fix the undefined reference. I believe that if you link to it publicly, then each individual sensor won't need to also link against register, only against ign-sensors's core library?

[ahcorde]

@chapulina, I was trying your suggestion but I'm not able to compile the code. I was having a look to other packages that make use of ignition-plugin and the approach it's similar to the one that I used here. For example:

• Ign-gui plugins include the register header in the .cc files. Not in the core library. Link1 Link2
• ign-gazebo. the same idea. Link3 Link4
• ign-rendering: Link5 Link6 Link7

[chapulina]

it's similar to the one that I used here

I think the key difference here is that the IGNITION_ADD_PLUGIN macro is used in SensorFactory, not in each plugin. All the examples you gave use that macro directly on the plugin files.

Does SensorFactory.hh work if you don't include Register.hh above it? If it doesn't, that sounds like an architecture flaw. A header should work when included by itself, without the need for extra includes above it, right?

[ahcorde]

All plugin are using the MACRO but it's hidden under this other one IGN_SENSORS_REGISTER_SENSOR

[ahcorde]

@chapulina I can remove IGN_SENSORS_REGISTER_SENSOR and make use of `IGNITION_ADD_PLUGIN.

[chapulina]

I can remove IGN_SENSORS_REGISTER_SENSOR and make use of `IGNITION_ADD_PLUGIN.

That sounds like a big migration effort for users. But since our support for custom sensors is not really there yet (#9), maybe this isn't a big deal. I'd be ok with it. What do you think, @iche033 ?

[ahcorde]

I noticed that the CI is not able to run the tests. But I'm not able to reproduce it in my machine. I will try on a docker container.

[chapulina]

I noticed that the CI is not able to run the tests. But I'm not able to reproduce it in my machine.

I'm seeing the same failures locally, i.e.

$ ./build/ignition-sensors4/bin/INTEGRATION_imu_plugin
[==========] Running 3 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 3 tests from ImuSensorTest
[ RUN      ] ImuSensorTest.CreateImu
[Err] [SensorFactory.cc:81] Unable to load sensor plugin file for [/home/chapulina/dome_ws/install/lib/libignition-sensors4-imu.so]
[Err] [SensorFactory.cc:166] Unable to instantiate sensor plugin for [ignition-sensors4-imu]
[Err] [SensorFactory.hh:133] Failed to create sensor of type[imu]
/home/chapulina/dome_ws/src/ign-sensors/test/integration/imu_plugin.cc:85: Failure
Value of: sensor != nullptr
  Actual: false
Expected: true
Segmentation fault (core dumped)

It looks like the shared library is generated and installed, but it doesn't have the correct symbols inside it.

[ahcorde]

@chapulina, regarding the failures in https://build.osrfoundation.org I have done some test inside a docker container and at least for Ubuntu I needed to add LD_LIBRARY_PATH=LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/ to make it work.

[chapulina]

A couple more comments.

And great work cleaning up the Windows warnings! Those could even be pushed to a separate PR so they can get merged faster.

[chapulina]

No other plugins have RegisterMore on their headers, can it be removed here?

[chapulina]

We shouldn't remove the CreateSensor tests, that function is still supported, right?

Instead, we should add separate tests for the Load functionality that you're using below.

[chapulina]

Just talked to @ahcorde , we'll save this for Ign-E so we have more time to try and test the new approach. Removing it from the Dome beta.

[chapulina]

This PR is outdated, it would be nice to sync it with the current main branch

[chapulina]

Removing beta label, we won't have time to wrap this up before code freeze. Let's retarget at Ignition-F.

[chapulina]

The plugin interface was completely removed on #90.