gazebosim / gz-plugin

Cross-platform C++ library for dynamically loading plugins.

Gazebo Plugin

Maintainer: ahcorde [AT] gmail [DOT] com

Build	Status
Test coverage
Ubuntu Jammy
Homebrew
Windows

Gazebo Plugin is a component in the Gazebo framework, a set of libraries designed to rapidly develop robot applications. It is used to register plugin libraries and load them dynamically at runtime.

http://gazebosim.org

Features

• Registration of templated and non-templated classes from any translation unit.
• Querying of interfaces by C++ type or name string.
• Dynamically load plugins at runtime according to the interfaces they provide.
• Reference counting of plugin objects to unload libraries no longer in use.
• Command line tool gz plugin to inspect plugins.

Installation

See the installation tutorial.

Documentation

Visit the documentation page.

gz-plugin's Issues

Provide Name accessor for Plugin class

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Migrated from https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-common/issues/32/provide-name-accessor-for-plugin-class (gazebosim/gz-common#32)

The name of a plugin is stored within the Info struct, but the Plugin class doesn't yet have an accessor for the name. It should be easy to add it.

Should provide GZ_ADD_PLUGIN as an alias to IGNITION_ADD_PLUGIN and friends

Desired behavior

It would be convenient to have GZ_ADD_PLUGIN in ign-plugin1 so we'd have less things to change when porting from Fortress to Garden

Alternatives considered

n/a

Implementation suggestion

Add aliases to Register.hh

#define GZ_ADD_PLUGIN(PluginClass, ...) \
  DETAIL_IGNITION_ADD_PLUGIN(PluginClass, __VA_ARGS__)

#define GZ_ADD_PLUGIN_ALIAS(PluginClass, ...) \
  DETAIL_IGNITION_ADD_PLUGIN_ALIAS(PluginClass, __VA_ARGS__)

#define GZ_ADD_FACTORY(ProductType, FactoryType) \
  DETAIL_IGNITION_ADD_FACTORY(ProductType, FactoryType)

#define GZ_ADD_FACTORY_ALIAS(ProductType, FactoryType, ...) \
  DETAIL_IGNITION_ADD_FACTORY_ALIAS(ProductType, FactoryType, __VA_ARGS__)

:farmer: CMake warning Policy CMP0153 is not set in gz-plugin1-homebrew

Environment

• OS Version: MacOS
• Source gz-plugin1

Description

• Expected behavior: gz-plugin1-homebrew is unstable due to CMake One Warning message
• Actual behavior: Build should be successful

Output

Reference build: https://build.osrfoundation.org/job/gz_plugin-ci-ign-plugin1-homebrew-amd64/37/

Output:

CMake Warning (dev) at /usr/local/share/cmake/ignition-cmake2/cmake2/IgnSetCompilerFlags.cmake:77 (exec_program):
  Policy CMP0153 is not set: The exec_program command should not be called.
  Run "cmake --help-policy CMP0153" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  Use execute_process() instead.
Call Stack (most recent call first):
  /usr/local/share/cmake/ignition-cmake2/cmake2/IgnSetCompilerFlags.cmake:33 (ign_setup_unix)
  /usr/local/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:88 (ign_set_compiler_flags)
  CMakeLists.txt:58 (ign_configure_build)
This warning is for project developers.  Use -Wno-dev to suppress it.

Configuring incomplete, errors occurred!

Actually, this is not a bug or an issue with the software but a general issue. While building my plugins using CMake on Ubuntu 18.04, the console threw this error given below.

CMake Error at CMakeLists.txt:10 (find_package):
  By not providing "Findcatkin.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "catkin", but
  CMake did not find one.

  Could not find a package configuration file provided by "catkin" with any
  of the following names:

    catkinConfig.cmake
    catkin-config.cmake

  Add the installation prefix of "catkin" to CMAKE_PREFIX_PATH or set
  "catkin_DIR" to a directory containing one of the above files.  If "catkin"
  provides a separate development package or SDK, be sure it has been
  installed.


Configuring incomplete, errors occurred!

I have implemented the source and header files for my plugin. I am not able to find info about how to generate CMakelIsts.txt file and .so for my plugin. In particular, I not able to generate the .so file. Any help is appreciated. Thanks,

Plugin loader could offer the option to load all known plugins

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Migrated from ignition common issue 15 (gazebosim/gz-common#15).

---

The plugin loader added on ign-common pull request 27 offers, among other things, interfaces to:

• add paths where to look for plugins
• load a library from a previously added path, given its filename
• list all loaded libraries

If one wants to list all the libraries available on the path, one needs to load all of them first. It would be nice if the plugin loader offered a function which automatically loads all libraries found in all registered paths.

missing license file

Description

Is this repository missing a License file ? Most of the ignition packages have a License file but I can't find one here

`gz_TEST` not running on Windows CI

Environment

• OS Version: Windows
• CI Source build

Description

Following the conversation on #128, the Windows CI still doesn't compile and run UNIT_gz_TEST. It looks like the workspace doesn't contain the package gz-tools2 or at least the workspace is not finding it.

Take a look

1. Take a look at one of the build in jenkins. Ex: https://build.osrfoundation.org/job/ign_plugin-pr-win/221/console
2. Look after the gz_TEST test and you will notice it is not there.

RTLD_LAZY vs RTLD_NOW in PluginLoader

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Migrated from https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-common/issues/34/rtld_lazy-vs-rtld_now-in-pluginloader (gazebosim/gz-common#34)

Looking at the PluginLoader implementation, we're using the RTLD_LAZY as the flag parameter when calling dlopen. Here's a description of the available flags.

Based on the documentation and a chat with @mxgrey, we conclude that Ignition Common doesn't have a particular preference between RTLD_LAZY or RTLD_NOW. The main implications seem to affect performance. RTLD_NOW front-loads some of the work when dlopen() is called at the cost of resolving symbols that might not be used. On the other hand, RTLD_LAZY returns faster from dlopen() but it will require to resolve the symbol the first time is really used.

To accommodate the different use cases from the Ignition Common users, we could expose the ability to choose the mode to the users. We discussed two options:

• Expose the flag at the PluginLoader class. All subsequent calls to LoadLibrary() will use the previously set flag.
• Expose the flag as a new LoadLibrary() parameter (possibly with a default option).

Add standalone executable for ign-plugin-info command

We updated the ign-transport ign topic and ign service commands to use standalone executables in gazebosim/gz-transport#216. We should do the same for the ign plugin --info command defined in the loader component:

• https://github.com/ignitionrobotics/ign-plugin/blob/ign-plugin1/loader/src/cmd/cmdplugin.rb.in

similar to gazebosim/gz-transport#247

LoadLibrary is a system function on Windows

Original report (archived issue) by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

---

Description

The function provided by ign-plugin LoadLibrary conflicts with a system macro in Windows.

Steps to Reproduce

1. Include windows.h in any file using LoadLibrary . i.e.:

diff -r 12ffb6a86ef0b3ba19310a5c8faa2d6bcb684c74 test/integration/plugin.cc
--- a/test/integration/plugin.cc        Fri Nov 02 17:58:25 2018 +0000
+++ b/test/integration/plugin.cc        Sat Dec 15 01:45:10 2018 +0100
@@ -30,6 +30,8 @@

 #include "../plugins/DummyPlugins.hh"
 #include "utils.hh"
+#include "windows.h"
+

 /////////////////////////////////////////////////
 TEST(Loader, LoadBadPlugins)

2. Compile it on Windows. The following error appears:

  c:\users\jrivero\code\ws_plugin\src\ign-plugin\test\integration\plugin.cc(50): error C2039: 'LoadLibraryA': is not a member of 'ignition::plugin::Lo
ader' [C:\Users\jrivero\code\ws_plugin\build\ignition-plugin1\test\integration\INTEGRATION_plugin.vcxproj]

Expected behavior:

Not to call system function but ign-plugin LoadLibrary

Actual behavior:

Compiler error.

Reproduces how often:

Always

Versions

Tested on default branch

Additional Information

Renaming the function and deprecate LoadLibrary comes to my mind as the easy way but not sure if we can find a better approach to solve it.

INTEGRATION_WeakPluginPtr test fails

Original report (archived issue) by Juan Oxoby (Bitbucket: Juan Oxoby).

---

Prerequisites

• [X ] Put an X between the brackets on this line if you have done all of the following:

  • Checked the Q&A board for common solutions: http://answers.gazebosim.org
  • Checked that your issue isn't already filed.
  • Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

INTEGRATION_WeakPluginPtr is failing on my machine.

Steps to Reproduce

1. Run INTEGRATION_WeakPluginPtr

Expected behavior:

PASSED

Actual behavior:

[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from WeakPluginPtr
[ RUN      ] WeakPluginPtr.Lifecycle
/home/juan/ignition_workspace/src/ign-plugin/test/integration/WeakPluginPtr.cc:59: Failure
Expected equality of these values:
  nullptr
    Which is: NULL
  dlHandle
    Which is: 0x55fdb805a330
[  FAILED  ] WeakPluginPtr.Lifecycle (0 ms)
[ RUN      ] WeakPluginPtr.CopyMove
[       OK ] WeakPluginPtr.CopyMove (0 ms)
[----------] 2 tests from WeakPluginPtr (0 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 1 test.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] WeakPluginPtr.Lifecycle

Reproduces how often:

Always

Versions

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:    18.04
Codename:   bionic

$ gcc --version
gcc (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Additional Information

The error points to the macro CHECK_FOR_LIBRARY defined on integration/utils.hh

There’s a comment there saying:

/////////////////////////////////////////////////
// Note (MXG): According to some online discussions, there is no guarantee
// that a correct number of calls to dlclose(void*) will actually unload the
// shared library. In fact, there is no guarantee that a dynamically loaded
// library from dlopen will ever be unloaded until the program is terminated.
// This may cause dlopen(~, RTLD_NOLOAD) to return a non-null handle even if
// we are managing the handles correctly. If the test for
// EXPECT_EQ(nullptr, dlHandle) is found to fail occasionally, we should
// consider removing it because it may be unreliable. At the very least, if
// it fails very infrequently, then we can safely consider the failures to be
// false negatives and may want to consider relaxing this test.

Avoiding the check EXPECT_EQ(nullptr, dlHandle) in the macro CHECK_FOR_LIBRARY makes the test pass.

Create first release

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

We just merged pull request #2, so I think we can make a prerelease. @_jrivero_ do you mind helping with the debian metadata? There are 3 components (core, loader, register).

cc @mxgrey

Feature request: ign tool support for introspecting plugin libraries

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Summary

It would be cool if we could add an ign command file that would enable introspection of a library file by listing the plugins and interfaces present in that library file.

ign plugin --info libPlugin.so

Motivation

It makes it more convenient for downstream users to inspect the interfaces provided by a given plugin library.

Describe alternatives you've considered

We could write a c++ executable instead of an ign tool command.

Additional context

None.