ros / pluginlib Goto Github PK

This issue was originally reported here pluginlib fails to build using clang compiler #678 on https://github.com/ros2/ros2 where it was suggested that I post the issue to this repository

Bug report

Required Info:

• Operating System:
  • Ubuntu 18.04
• Installation type:
  • source
• Version or commit hash:
  • release-latest bbf4dd1371df02b3f446dacd4bb4f6aed181db14
• DDS implementation:
  • Fast-RTPS
• Client library (if applicable):
  • pluginlib

Steps to reproduce issue

Dockerfile:

FROM ubuntu:18.04

ENV CHOOSE_ROS_DISTRO=crystal

RUN echo 'Etc/UTC' > /etc/timezone && \
    ln -s /usr/share/zoneinfo/Etc/UTC /etc/localtime && \
    apt-get update && apt-get install -q -y tzdata curl gnupg2 lsb-release \
    && curl http://repo.ros2.org/repos.key | apt-key add - \
    && sh -c 'echo "deb [arch=amd64,arm64] http://packages.ros.org/ros2/ubuntu `lsb_release -cs` main" > /etc/apt/sources.list.d/ros2-latest.list'  \   
    && rm -rf /var/lib/apt/lists/*

# Install tools
RUN apt-get update --fix-missing && apt-get install -y \
    build-essential \
    cmake \
    git \
    python3-colcon-common-extensions \
    python3-pip \
    python-rosdep \
    python3-vcstool \
    wget \
    libasio-dev \
    libtinyxml2-dev \
    clang \
    clang-tidy \
# install some pip packages needed for testing
    && python3 -m pip install -U \
    argcomplete \
    flake8 \
    flake8-blind-except \
    flake8-builtins \
    flake8-class-newline \
    flake8-comprehensions \
    flake8-deprecated \
    flake8-docstrings \
    flake8-import-order \
    flake8-quotes \
    git+https://github.com/lark-parser/[email protected] \
    pytest-repeat \
    pytest-rerunfailures \
    pytest \
    pytest-cov \
    pytest-runner \
    setuptools \ 
    && rm -rf /var/lib/apt/lists/*

#Setup ROS2 code for compile
WORKDIR /root/ros2_ws/ros2_base

# ADD ros2.repos /root/ros2_ws/ros2_base/ros2.repos
RUN wget https://raw.githubusercontent.com/ros2/ros2/release-latest/ros2.repos \
    && mkdir src \
    && vcs import src < ros2.repos \
    && rosdep init \
    && apt-get update && rosdep update \
    && rosdep install --from-paths src --ignore-src --rosdistro crystal -y --skip-keys "console_bridge fastcdr fastrtps libopensplice67 libopensplice69 rti-connext-dds-5.3.1 urdfdom_headers" \
    && rm -rf /var/lib/apt/lists/*

ENV CC=/usr/bin/clang
ENV CXX=/usr/bin/clang++

WORKDIR /root/ros2_ws/ros2_base
RUN colcon build --cmake-args -DCMAKE_BUILD_TYPE=DEBUG --merge-install

docker build -f Dockerfile -t ros2source:latest .

Expected behavior

Successful build of the docker container

Actual behavior

[Processing: pluginlib, test_msgs]
--- stderr: pluginlib
CMakeFiles/pluginlib_unique_ptr_test.dir/test/unique_ptr_test.cpp.o: In function `pluginlib::ClassLoader<test_base::Fubar>::getPackageFromPluginXMLFilePath(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
unique_ptr_test.cpp:(.text._ZN9pluginlib11ClassLoaderIN9test_base5FubarEE31getPackageFromPluginXMLFilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN9pluginlib11ClassLoaderIN9test_base5FubarEE31getPackageFromPluginXMLFilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x59): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::parent_path() const'
unique_ptr_test.cpp:(.text._ZN9pluginlib11ClassLoaderIN9test_base5FubarEE31getPackageFromPluginXMLFilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN9pluginlib11ClassLoaderIN9test_base5FubarEE31getPackageFromPluginXMLFilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x241): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::parent_path() const'
CMakeFiles/pluginlib_unique_ptr_test.dir/test/unique_ptr_test.cpp.o: In function `std::experimental::filesystem::v1::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::experimental::filesystem::v1::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
unique_ptr_test.cpp:(.text._ZNSt12experimental10filesystem2v17__cxx114pathC2INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES3_EERKT_[_ZNSt12experimental10filesystem2v17__cxx114pathC2INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES3_EERKT_]+0x5e): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
CMakeFiles/pluginlib_unique_ptr_test.dir/test/unique_ptr_test.cpp.o: In function `std::experimental::filesystem::v1::exists(std::experimental::filesystem::v1::__cxx11::path const&)':
unique_ptr_test.cpp:(.text._ZNSt12experimental10filesystem2v16existsERKNS1_7__cxx114pathE[_ZNSt12experimental10filesystem2v16existsERKNS1_7__cxx114pathE]+0x11): undefined reference to `std::experimental::filesystem::v1::status(std::experimental::filesystem::v1::__cxx11::path const&)'
CMakeFiles/pluginlib_unique_ptr_test.dir/test/unique_ptr_test.cpp.o: In function `std::experimental::filesystem::v1::__cxx11::path::path<char [12], std::experimental::filesystem::v1::__cxx11::path>(char const (&) [12])':
unique_ptr_test.cpp:(.text._ZNSt12experimental10filesystem2v17__cxx114pathC2IA12_cS3_EERKT_[_ZNSt12experimental10filesystem2v17__cxx114pathC2IA12_cS3_EERKT_]+0x5b): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
CMakeFiles/pluginlib_unique_ptr_test.dir/test/unique_ptr_test.cpp.o: In function `std::experimental::filesystem::v1::__cxx11::path::_M_append(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
unique_ptr_test.cpp:(.text._ZNSt12experimental10filesystem2v17__cxx114path9_M_appendERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZNSt12experimental10filesystem2v17__cxx114path9_M_appendERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x9b): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
CMakeFiles/pluginlib_unique_ptr_test.dir/test/unique_ptr_test.cpp.o: In function `std::experimental::filesystem::v1::__cxx11::path::clear()':
unique_ptr_test.cpp:(.text._ZNSt12experimental10filesystem2v17__cxx114path5clearEv[_ZNSt12experimental10filesystem2v17__cxx114path5clearEv]+0x1e): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [pluginlib_unique_ptr_test] Error 1
make[1]: *** [CMakeFiles/pluginlib_unique_ptr_test.dir/all] Error 2
make: *** [all] Error 2
---
Failed   <<< pluginlib  [ Exited with code 2 ]

Additional information

root@b8f13126204c:~/ros2_ws/ros2_base# clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

I'm having some trouble loading a plugin and decided to open an issue to see if it's even possible. I am creating package_B where i'm creating a class that implements a plugin base class that exists in package_A.

Also, somewhere in package_A, they call loader->createInstance(plugin_type). When plugin_type equals the plugin i've created in package_B, it fails saying the plugin doesn't exist. But when the plugin type is one of the plugins created/exported from package_A, it works just fine. I feel like maybe pluginlib isn't built to do what i'm trying to make it do. Thoughts?

refreshDeclaredClasses() (http://docs.ros.org/hydro/api/pluginlib/html/class__loader__imp_8h_source.html#l00619) makes use of ros::package to find new plugins (see getPluginXmlPaths: http://docs.ros.org/hydro/api/pluginlib/html/class__loader__imp_8h_source.html#l00177). However, in the most cases newly available plugins are probably not yet in the cache. Hence getPluginXmlPaths() should use call rospack profile (or something similar) to update the cache before looking for new plugins.

To fix #37, I tried to enable on-demand loading/unloading. However, now classes cannot be instantiated:

terminate called after throwing an instance of 'pluginlib::CreateClassException'
  what():  MultiLibraryClassLoader: Could not create object of class type test_plugins::Foo as no factory exists for it. Make sure that the library exists and was explicitly loaded through MultiLibraryClassLoader::loadLibrary()
The program has unexpectedly finished.

Should inheritance 'chains' be possible with plugins? i.e., Base Class > Derived Class 1 > Derived Class 2.

My problem: I want to build a plugin (rviz::OmniTool) that uses rviz::InteractionTool as a base. But rviz::InteractionTool is already derived from rviz::Tool. So the desired inheritance is rviz::Tool > rviz::InteractionTool > rviz::OmniTool.

The problem is that rviz::OmniTool doesn't show up in rviz, although it does get returned by rospack plugins, so pluginlib knows it exists. However, if I change it to be derived directly from rviz::Tool, it shows up just fine.

Does this sound like a problem with pluginlib or rviz?

I suspect it's this change: 099d776

http://jenkins.willowgarage.com:8080/view/GbinP64/job/ros-groovy-nodelet_binarydeb_precise_amd64/82/console

I was refactoring code, and mistakenly didn't change the export tags on a plugin. Hence there were no available plugins for the given type.

terminate called after throwing an instance of 'pluginlib::LibraryLoadException'
  what():  rospack could not find the layered_costmap package containing layered_costmap::CostmapPlugin

Program received signal SIGABRT, Aborted.
0x00007ffff6b05425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6b05425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6b08b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff715b69d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff7159846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff7159873 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff715996e in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff73e139f in pluginlib::ClassLoader<layered_costmap::CostmapPlugin>::determineAvailableClasses (this=0x7fffffffe010)
    at /opt/ros/fuerte/stacks/pluginlib/include/pluginlib/class_loader_imp.h:418
#7  0x00007ffff73e1947 in pluginlib::ClassLoader<layered_costmap::CostmapPlugin>::ClassLoader (this=0x7fffffffe010, package=..., base_class=..., 
    attrib_name=...) at /opt/ros/fuerte/stacks/pluginlib/include/pluginlib/class_loader_imp.h:51
#8  0x00007ffff73cb25a in layered_costmap::LayeredCostmap::LayeredCostmap (this=0x7fffffffdd40, name=..., tf=...)
    at /wg/stor5/dlu/ros/navigation/layered_costmap/src/layered_costmap.cpp:50

in MoveIt there exists packages whose's folder name does not match their package name - ie moveit_ros_visualization is located in the folder moveit_ros/visualization. pluginlib assumes that your package name is the same as the folder name. it calls ros::package ::getPath(package_name) and makes sure it matches the current package's location. the fix seems to me to be instead of assuming the package name is the folder name containing "package.xml", instead read the located package.xml and get the package name from there

the issue can be found in class_loader_imp.h, function getPackageFromPluginXMLFilePath() here:

std::string package_path = ros::package ::getPath(package);
if (path.find(package_path) == 0)

@isucan

The thing is like this:

I compile the boost of version 1.65 into my computer. And I build a package with pluginlib in it. I compile it over. But when I run the node, it will result in a segment fault. Like this:

gdb ./polygon_loader 
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./polygon_loader...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/wangyawei/RosWorkspace/common_tutorials_ws/devel/lib/pluginlib_tutorials/polygon_loader 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x2) at malloc.c:2951
2951    malloc.c: No such file or directory.

So the problem is segment fault.
When I remove the path /usr/local/include/boost and /usr/local/lib/libboost* and recompile the package and the error is gone.

So I check the version of the two kind of boost: 1.58 for origin ros and 1.65 for my compile. Maybe there are different point between two kinds version.

But I want to know could anyone update the pluginlib for the latest version of boost?

In this deprecated header:

Possible solutions:

• Use #pragma message("...")
• Surround #warning checking for compiler
• Remove the deprecated header and break things

More discussion about solutions
https://stackoverflow.com/questions/2685598/warning-in-visual-studio

Programming is not really my strong suit and I really have no idea what went wrong here:

pkg_1::derived_1:
base_class: pkg_2::derived_2
init(a,b,c);
getAllIK(a,b,c);

pkg_2::derived_2:
base_class: pkg_3::base
init(a,b,c);
getAllIK(a,b,c);
... a couple more

pkg_3::base:
init(a,b,c);
getAllIK(a,b,c);
... a couple more

//other_code
static pluginlib::ClassLoader<pkg_name::base> r_model_loader("pkg_3", "pkg_3::base");
basePtr ptr = r_model_loader.createInstance("pkg1::derived_1");

When i call the function init(a,b,c) , the function called is the one in derived_2. When i call getAllIK, the function called is in derived_1 , but it doesn't receive the values from the call and instead gets junk. The calls are identical. Sometimes segfaults happen.

Base is defined in the header base.h , and all of its functions are actually in derived_2. In my code I am loading derived_2 with plugin lib as follows:

I have exported the derived_1 plugin with the base declared as "pkg_name::base" but that didn't help. Does anyone have any idea what might be the problem?

See http://answers.ros.org/question/173255/compiling-ros-to-virtual-nao/
After calling catkin_add_gtest the target can only be used if it actually exists since when the user does not have gtest no target is created.

Inside class_loader_imp.h there are a couple of calls specific to boost filesystem v3 that won't compile on projects using v2. There are just two of them: native() and filename().string(). We could use the macro BOOST_FILESYSTEM_VERSION to detect the version in use and then call the appropriate function. If this makes sense I can submit a pull request with the changes.

Concerning the ROS2 branch

I have a problem when compiling object files using the pluginlib, when I get the following error:
/include/pluginlib/class_list_macros.hpp:49:59: error: extra ‘;’ [-Werror=pedantic] CLASS_LOADER_REGISTER_CLASS(class_type, base_class_type);

It's claiming that one should remove the last ";" in this line:

I sadly can't provide a PR at the moment.

pluginlib page has a few things that are out of date though the API stays the same, particularly for groovy.

-in groovy, package.xml holds export tag instead of manifest.xml
-pluginlib now sits on class_loader (create a link)
-warn about linking directly against libs (mirror from class_loader wiki page)
-clarify new features such as thread safety and ability to introspect an arbitrary library

See also https://groups.google.com/d/topic/ros-sig-buildsystem/hsxeJocnKIQ/discussion

We desire to introduce pluginlib as a dependency for packages inside ros_comm without creating a repo-level circular dependency, which would presently be the case on account of rosconsole being inside ros_comm (see ros/ros_comm#1206).

An obvious solution is to extract rosconsole into its own repo, but I wonder about breaking the dependency on this end, too. Excluding tests, all usages of logging in this repo are as follows:

$ grep -r \ ROS_ *
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Creating ClassLoader, base = %s, address = %p",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Destroying ClassLoader, base = %s, address = %p",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Instance created with object pointer = %p", obj);
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "CreateClassException about to be raised for class %s",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Attempting to create managed instance for class %s.",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "%s maps to real class type %s",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "boost::shared_ptr to object of real type %s created.",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "%s maps to real class type %s",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "std::unique_ptr to object of real type %s created.",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Attempting to create UNMANAGED instance for class %s.",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "%s maps to real class type %s",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Instance of type %s created.", class_type.c_str());
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Entering determineAvailableClasses()...");
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Exiting determineAvailableClasses()...");
include/pluginlib/class_loader_imp.h:    ROS_ERROR_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_ERROR_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Class %s has no mapping in classes_available_.",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Class %s maps to library %s in classes_available_.",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Checking path %s ", it->c_str());
include/pluginlib/class_loader_imp.h:      ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Library %s found at explicit path %s.",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Class %s has no mapping in classes_available_.",
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "No path could be found to the library containing %s.",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Processing xml file %s...", xml_file.c_str());
include/pluginlib/class_loader_imp.h:      ROS_ERROR_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:      ROS_ERROR_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:        ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:        ROS_DEBUG_NAMED("pluginlib.ClassLoader",
include/pluginlib/class_loader_imp.h:  ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Refreshing declared classes.");
include/pluginlib/class_loader_imp.h:    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Attempting to unload library %s for class %s",

The main issue with switching this is that console_bridge doesn't have the concept of named loggers the way rosconsole does, so that would be lost, however it seems like there may be some logic within rosconsole_bridge that attempts to recover a prefix embedded in the log string itself:

https://github.com/ros/rosconsole_bridge/blob/8e27f6ef86c84b78d9fd20d883923fca70ba3532/src/bridge.cpp#L56-L75

Would a PR that switches this over be acceptable to the maintainers?

Related to jsk-ros-pkg/jsk_recognition#2298 and moveit/moveit#827 (comment)

Moveit 0.9.12 requires the commit 84b0c46, which have not been released yet.
I request to release 0.9.13 in Kinetic, too.

@mikaelarguedas mentioned in #42 (comment) that the new createUniqueInstance interface will be released into indigo and jade too.

It would be great to see this happen in the near future!
MoveIt's main development branch (kinetic-devel) requires this feature.
In order to use the branch with ROS indigo, currently one has to overlay the /opt/ros/indigo version of pluginlib in the workspace.
It is not easy to upgrade many robotic setups, so this kind of cross-versioning is not too uncommon.

I'm using plugins in a pure catkin environment, where both the plugins and the code that calls the plugins is in catkin. When instantiating the plugin loader, I get the following (meaningless?) error:

[ERROR] [1351729666.226378607]: Could not find package name for class /home/wim/stacks/groovy/catkin_ws/src/joint_state_controller/joint_state_plugin.xml

What does this mean? The xml file is a class? Does it fail to find a package, or just the name of a package? I'm not sure what to make of this.

It would also be great if the error message could be much more meaningful, so I'd have some idea of what to fix.

When starting a large project, it is difficult to determine where the pluginlib macro warnings are coming from. It would be useful if the macro included the filename where it was invoked.

pluginlib fails to install as I try to install ROS (Hydro) from source code on my Ubuntu 12.04.
I followed this article to install ros from source. http://wiki.ros.org/Installation/Source

make -j8 -l8 in '/home/eeuser/installation_ros_src_ws/build_isolated/pluginlib'
Linking CXX executable /home/eeuser/installation_ros_src_ws/devel_isolated/pluginlib/lib/pluginlib/plugin_tool
/home/eeuser/installation_ros_src_ws/install_isolated/lib/libclass_loader.so: error: undefined reference to 'pthread_mutexattr_init'
/home/eeuser/installation_ros_src_ws/install_isolated/lib/libclass_loader.so: error: undefined reference to 'pthread_mutexattr_settype'
/home/eeuser/installation_ros_src_ws/install_isolated/lib/libclass_loader.so: error: undefined reference to 'pthread_mutexattr_destroy'
collect2: ld returned 1 exit status
make[2]: *** [/home/eeuser/installation_ros_src_ws/devel_isolated/pluginlib/lib/pluginlib/plugin_tool] Error 1
make[1]: *** [CMakeFiles/plugin_tool.dir/all] Error 2
make: *** [all] Error 2
<== Failed to process package 'pluginlib':
Command '/home/eeuser/installation_ros_src_ws/install_isolated/env.sh make -j8 -l8' returned non-zero exit status 2

Reproduce this error by running:
==> cd /home/eeuser/installation_ros_src_ws/build_isolated/pluginlib && /home/eeuser/installation_ros_src_ws/install_isolated/env.sh make -j8 -l8

Command failed, exiting.

I want to open with a thank you to the maintainers of these core packages. I hope I'm not too obnoxious in my questioning.

I have recently written an application that crunches numbers in a distributed fashion and uses ROS plugins to help do some of that work. I am running into issues that appear to be related to the threading I'm doing. Specifically, I am:

• spawning I threads
• each thread then creates J instances of a particular plugin
• these threads then stay alive and accept work through another interface

What I'm finding is that with sufficiently high contention, on ROS Indigo, a plugin will eventually fail to load. With a single thread, or mutex protected access it works fine consistently.

I have modified the pluginlib tutorial code to provide a minimal example of this bug:

#include <iostream>
#include <boost/shared_ptr.hpp>
#include <boost/thread.hpp>

#include <pluginlib/class_loader.h>
#include <pluginlib_tutorials/polygon_base.h>
#include <boost/ref.hpp>

typedef boost::shared_ptr<polygon_base::RegularPolygon> RegularPolygonPtr;

static RegularPolygonPtr loadPlugin(pluginlib::ClassLoader<polygon_base::RegularPolygon>& loader)
{
  try
  {
    RegularPolygonPtr plugin = loader.createInstance("pluginlib_tutorials/regular_triangle");
    return plugin;
  }
  catch (std::exception& e)
  {
    std::cerr << "An error occured: " << e.what() << "\n";
    return RegularPolygonPtr();
  }
}

// Experiment 1: Each worker has its own class loader
void workerThread1(int n)
{
  pluginlib::ClassLoader<polygon_base::RegularPolygon> loader ("pluginlib_tutorials", "polygon_base::RegularPolygon");
  std::vector<RegularPolygonPtr> plugins;

  for (int i = 0; i < n; ++i)
  {
    RegularPolygonPtr plugin = loadPlugin(loader);
    if (plugin) plugin->initialize(10.0);
    plugins.push_back(plugin);
  }

  boost::this_thread::sleep(boost::posix_time::milliseconds(1000));
}

void launchExperiment1(int n_threads, int n)
{
  std::vector<boost::thread*> threads;
  for (int i = 0; i < n_threads; ++i)
  {
    threads.push_back( new boost::thread(workerThread1, n) );
  }

  for (int i = 0; i < n_threads; ++i)
  {
    threads[i]->join();
    delete threads[i];
  }
}

// Experiment 2: All workers share a class loader
void workerThread2(int n, pluginlib::ClassLoader<polygon_base::RegularPolygon>& loader)
{
  std::vector<RegularPolygonPtr> plugins;

  for (int i = 0; i < n; ++i)
  {
    RegularPolygonPtr plugin = loadPlugin(loader);
    if (plugin) plugin->initialize(10.0);
    plugins.push_back(plugin);
  }

  boost::this_thread::sleep(boost::posix_time::milliseconds(1000));
}

void launchExperiment2(int n_threads, int n)
{
  pluginlib::ClassLoader<polygon_base::RegularPolygon> loader ("pluginlib_tutorials", "polygon_base::RegularPolygon");
  std::vector<boost::thread*> threads;
  for (int i = 0; i < n_threads; ++i)
  {
    threads.push_back( new boost::thread(workerThread2, n, boost::ref(loader)) );
  }

  for (int i = 0; i < n_threads; ++i)
  {
    threads[i]->join();
    delete threads[i];
  }
}

int main(int argc, char** argv)
{
  if (argc < 3)
  {
    std::cerr << "Usage: ./polygon_loader <n_threads> <n_items_per_thread>";
    return 1;
  }

  int n_threads = std::atoi(argv[1]);
  int n_items_per_thread = std::atoi(argv[2]);

  std::cout << "Starting multi-threaded loading experiment w/ " << n_threads << " threads " <<
            "and " << n_items_per_thread << " plugins per thread" << std::endl;

  std::cout << "Experiment 1: All threads have own class loader" << std::endl;
  launchExperiment1(n_threads, n_items_per_thread);
  std::cout << "Experiment 2: All threads share a class loader" << std::endl;
  launchExperiment2(n_threads, n_items_per_thread);
  return 0;
}

If you build this in place of the existing polygon_loader.cpp file in this package you can reproduce the issue. On my machine, you'll see errors with rosrun polygon_loader 100 500 pretty consistently.

Is this a known issue? Does the pluginlib make any guarantees about thread safety (I see that the separate class_loader package says its thread safe)?

Synchronously loading plugins is not a very viable solution. If you need more information, I'm happy to help provide it.

I've an architecture where I've the plugins has to have arguments passed to its constructors,

sth like this AuthorPlugin::AuthorPlugin(QWidget* parent) : SetupAssistantWidget(parent) and the SetupAssistantWidget is the interface, is there a way to do that with pluginlib?

I'm using plugins in a pure catkin environment, where both the plugins and the code that calls the plugins is in catkin. When instantiating the plugin loader, I get the following (meaningless?) error:

[ERROR] [1351729666.226378607]: Could not find package name for class /home/wim/stacks/groovy/catkin_ws/src/joint_state_controller/joint_state_plugin.xml

What does this mean? The xml file is a class? Does it fail to find a package, or just the name of a package? I'm not sure what to make of this.

Browsing through the pluginlib code, I noticed it's still looking for a manifest.xml, which is pre-catkin. Is pluginlib tested in the pure catkin situation I'm working in?

It would also be great if the error message could be much more meaningful, so I'd have some idea of what to fix.

As mentioned in ros-visualization/qt_gui_core#114.

E.g. http://build.ros.org/job/Mpr__qt_gui_core__ubuntu_bionic_amd64/1/warnings22Result/

I thought it might be interesting to expose some of the class_loader functionality like introspection of classes and the ability to create plugins from real class name. This could serve as a way for users to stop using the "magic name" for plugins and use the real nae instead (down the line).

nts: How to get users to use new PLUGINLIB_DECLARE_CLASS_SIMPLE macro instead?

Asking out of curiosity, why are we keeping both .h and .hpp header files at the same time?

The deprecation warnings should be removed though

As the definition of the package says: "pluginlib is a C++ library for loading and unloading plugins from within a ROS package". The implementation of that is that every plugin is build as a shared library.

In the case that ROS was installed in /usr to follow FHS instead that /opt/ros/$distro/lib, a ros installation with multiple packages providing plugins the /usr/lib/* (or /usr/lib/$arch/*) directories contain a bunch of "libraries" that are not public libraries for the system installed in the place of public libraries. This consideration could be applied to /opt/ros/$distro/lib.

So, the plugins created by this library should go so some directory inside the default library path (i.e. /opt/ros/$distro/lib/ros-plugins or /usr/lib/ros/plugins or /usr/lib/ros or /usr/lib/pluginlib or whatever you consider appropriate.

Some references could be found here:

http://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/plugin.html
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

I cannot evaluate the implications of that change (catkin, LD_LIBRARY_PATH, RUNPATH, etc), but it should be consider.

http://www.ros.org/wiki/pluginlib/Tutorials/Writing%20and%20Using%20a%20Simple%20Plugin?action=recall&rev=24
As of this revision, choosing groovy shows the right content of plugin.xml but fuerte and electric still shows the same.

Root cause is in the macro's bug, which is issued ros-infrastructure/roswiki#17

I feel like somebody must have asked this already, but I was unable to find the issue if they have, so i'll ask. Are there any plans to phase out the boost::shared_ptr in favor of std::shared_ptr?

System information: 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux

Building ROS Lunar from source as directed here: http://wiki.ros.org/Installation/Source. At the step ./src/catkin/bin/catkin_make_isolated --install -DCMAKE_BUILD_TYPE=Release, during compilation of pluginlib, the executable plugin_tool fails at the linking step with the following error:

librosconsole.so: undefined reference to boost::re_detail::cpp_regex_traits_implementation<char>::transform[abi:cxx11](char const*, char const*) const' librosconsole.so: undefined reference to boost::re_detail::raise_runtime_error(std::runtime_error const&)'
librosconsole.so: undefined reference to boost::re_detail::put_mem_block(void*)' librosconsole.so: undefined reference to boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > >, boost::regex_traits<char, boost::cpp_regex_traits > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits > > const&, boost::regex_constants::_match_flags)'
librosconsole.so: undefined reference to boost::re_detail::get_mem_block()' librosconsole.so: undefined reference to boost::re_detail::verify_options(unsigned int, boost::regex_constants::_match_flags)'
librosconsole.so: undefined reference to boost::re_detail::get_default_error_string(boost::regex_constants::error_type)' librosconsole.so: undefined reference to boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char const*, char const*) const'
collect2: error: ld returned 1 exit status

Hi.
I found this problem when debugging image_transport library.

To get library path, pluginlib uses popen("catkin_pkg --libs", "r") .
Sometimes popen failes memory is not enough.
On such situation, pluginlib returns incompletion lib paths without any error report.

I think there are 2 solutions for this problem.

1. throwing exception when popen returns error.
2. instead of popen uses native api.

This happens when I add a camera display in rviz.

rviz: 0f71e032dbe5310e78054cb0f7b10c62aa2ac4df
pluginlib: f684438
#0 0x00007ffff45405c0 in class_loader::class_loader_private::purgeGraveyardOfMetaobjects(std::string const&, class_loader::ClassLoader*, bool) () from /opt/ros/groovy/lib/libclass_loader.so
#1 0x00007ffff4542e50 in class_loader::class_loader_private::loadLibrary(std::string const&, class_loader::ClassLoader*) ()

from /opt/ros/groovy/lib/libclass_loader.so
#2 0x00007ffff453f216 in class_loader::ClassLoader::loadLibrary() () from /opt/ros/groovy/lib/libclass_loader.so
#3 0x00007ffff453f3b8 in class_loader::ClassLoader::ClassLoader(std::string const&, bool) () from /opt/ros/groovy/lib/libclass_loader.so
#4 0x00007ffff4545dd0 in class_loader::MultiLibraryClassLoader::loadLibrary(std::string const&) ()

from /opt/ros/groovy/lib/libclass_loader.so
#5 0x00007ffff7ae2480 in pluginlib::ClassLoader<image_transport::SubscriberPlugin>::loadLibraryForClass (this=0x7fffffffc230,

lookup_name=...) at /wg/stor5/dgossow/wsrviz/src/pluginlib/include/pluginlib/class_loader_imp.h:484

#6 0x00007ffff7aeb07c in pluginlib::ClassLoader<image_transport::SubscriberPlugin>::createInstance (this=0x7fffffffc230,

lookup_name=...) at /wg/stor5/dgossow/wsrviz/src/pluginlib/include/pluginlib/class_loader_imp.h:125

#7 0x00007ffff7adb840 in rviz::ImageDisplayBase::scanForTransportSubscriberPlugins (this=0x1ef6520)

at /wg/stor5/dgossow/wsrviz/src/rviz/src/rviz/image/image_display_base.cpp:188

#8 0x00007ffff7adc001 in rviz::ImageDisplayBase::ImageDisplayBase (this=0x1ef6520)

at /wg/stor5/dgossow/wsrviz/src/rviz/src/rviz/image/image_display_base.cpp:71

#9 0x00007fffac3fd8e9 in rviz::CameraDisplay::CameraDisplay (this=0x1ef6520)

at /wg/stor5/dgossow/wsrviz/src/rviz/src/rviz/default_plugin/camera_display.cpp:85

#10 0x00007fffac4061ea in class_loader::class_loader_private::MetaObject<rviz::CameraDisplay, rviz::Display>::create (

this=<optimized out>) at /opt/ros/groovy/include/class_loader/meta_object.h:210

#11 0x00007ffff7ac8393 in class_loader::class_loader_private::createInstancerviz::Display (derived_class_name=..., loader=0x17cd670)

at /opt/ros/groovy/include/class_loader/class_loader_core.h:211

#12 0x00007ffff7ac86cf in createUnmanagedInstancerviz::Display (derived_class_name=..., this=0x17cd670)

at /opt/ros/groovy/include/class_loader/class_loader.h:115

#13 class_loader::MultiLibraryClassLoader::createUnmanagedInstancerviz::Display (this=, class_name=...)

at /opt/ros/groovy/include/class_loader/multi_library_class_loader.h:117

#14 0x00007ffff7ac884c in pluginlib::ClassLoaderrviz::Display::createUnmanagedInstance (this=0x2c1b1c0, lookup_name=...)

at /wg/stor5/dgossow/wsrviz/src/pluginlib/include/pluginlib/class_loader_imp.h:160

#15 0x00007ffff7ac8fe2 in rviz::PluginlibFactoryrviz::Display::makeRaw (this=0x2b9f250, class_id=..., error_return=0x7fffffffc920)

at /opt/ros/groovy/include/rviz/pluginlib_factory.h:170

#16 0x00007ffff7abeb43 in rviz::DisplayFactory::makeRaw (this=0x2b9f250, class_id=..., error_return=)

at /wg/stor5/dgossow/wsrviz/src/rviz/src/rviz/display_factory.cpp:50

#17 0x00007ffff7abfd24 in rviz::ClassIdRecordingFactoryrviz::Display::make (this=0x2b9f250, class_id=..., error_return=)

at /opt/ros/groovy/include/rviz/class_id_recording_factory.h:57

#18 0x00007ffff7acb976 in rviz::DisplayGroup::createDisplay (this=, class_id=...)

at /wg/stor5/dgossow/wsrviz/src/rviz/src/rviz/display_group.cpp:120

#19 0x00007ffff7b6440d in rviz::VisualizationManager::createDisplay (this=0x2b53630, class_lookup_name=..., name=..., enabled=true)

at /wg/stor5/dgossow/wsrviz/src/rviz/src/rviz/visualization_manager.cpp:479

#20 0x00007ffff7acdb24 in rviz::DisplaysPanel::onNewDisplay (this=0x2c95c00)

http://jenkins.ros.org/job/devel-indigo-pluginlib/11/
http://jenkins.ros.org/job/devel-jade-pluginlib/3/

I have a couple of classes where the exported plugin name cannot be equal to the class name.

https://github.com/PR2/pr2_ethercat_drivers/blob/hydro-devel/ethercat_hardware/src/wg014.cpp

The exported plugin is a driver for a specific model of device, and the exported name is the model number of the device. This means that the top-level node can find drivers for a particular device by querying the device model number and then searching for a plugin with the same name.

need ros-visualization/qt_gui_core#96 and ros-visualization/qt_gui_core#97 to be integrated to the groovy-devel branch and released before releasing pluginlib

There is a new package called cmake_modules, which we just created:

https://github.com/ros/cmake_modules

It provides a common FindTinyXML.cmake CMake module, which we should all try to use in order to prevent issues when doing things like cross-compiling.

This is a low priority, but a good idea. The package is available for Hydro and Groovy, it will be in public on the next sync.

From ros/rosdistro#4192 It looks like this should have been a 1.10 release.

If the workspace that contains the pluginlib and class_loader packages are compiled with catkin_make -DCMAKE_BUILD_TYPE="Debug" command, the plugins cannot be loaded.

For example trying to load image_transport/raw_pub plugin produces the following logs

[DEBUG] [1379221062.565758000]: Attempting to create managed instance for class image_transport/raw_pub.
[DEBUG] [1379221062.565798000]: Class image_transport/raw_pub maps to library lib/libimage_transport_plugins in classes_available_.
[DEBUG] [1379221062.671369000]: Iterating through all possible paths where lib/libimage_transport_plugins could be located...
[DEBUG] [1379221062.673023000]: Checking path /Users/murat/ros/common_ws/devel/lib/lib/libimage_transport_pluginsd.dylib 
[DEBUG] [1379221062.673180000]: Checking path /Users/murat/ros/common_ws/devel/lib//libimage_transport_pluginsd.dylib 
[DEBUG] [1379221062.673327000]: Checking path /Users/murat/ros/core_ws/devel/lib/lib/libimage_transport_pluginsd.dylib 
[DEBUG] [1379221062.673495000]: Checking path /Users/murat/ros/core_ws/devel/lib//libimage_transport_pluginsd.dylib 
[DEBUG] [1379221062.674935000]: No path could be found to the library containing image_transport/raw_pub.
[ WARN] [1379221062.675168000]: Failed to load plugin image_transport/raw_pub, error string: Could not find library corresponding to plugin image_transport/raw_pub. Make sure the plugin description XML file has the correct name of the library and that the library actually exists.

I figured this is because the debug builds are linked against debug version of Poco library, which uses d.dylib suffix for shared libraries on OS X. On the other hand all plugin libraries have .dylib suffix even if they are compiled using Debug build type.

Poco 1.4.6p1 is installed on the system via Homebrew

I occasionally need to build ros packages using Debug build type to debug other problems. This issue comes up whenever I do that.

Hi,
I am trying to install the package in ROS indigo and VREP3_3_2
when I run VREP, It cann't load the RosBridge

Plugin 'RosBridge': loading...
[rospack] Error: package 'vrep_ros_plugin' not found
[librospack]: error while executing command
terminate called after throwing an instance of 'pluginlib::ClassLoaderException'
what(): Unable to find package: vrep_ros_plugin
Aborted (core dumped)

I have two packages that I define my plugins in them, costmap_2d, and my_costmap. Plugin files in my_costmap package are as below

my_costmap_plugins.xml:

<library path="lib/libmy_costmap_layer">
  <class type="my_costmap::ProbabilisticLayer"  base_class_type="costmap_2d::Layer">
    <description>Listens to ...</description>
  </class>
  <class type="my_costmap::SpecifiedCostLayer"  base_class_type="costmap_2d::Layer">
    <description>Listens to...</description>
  </class>
</library>

package.xml

<export>
    <costmap_2d plugin="${prefix}/my_costmap_plugins.xml"/>
  </export>

specified_cost_layer.cpp
Added PLUGINLIB_EXPORT_CLASS(my_costmap::SpecifiedCostLayer, costmap_2d::Layer)

In another package (my_package_2), I created an instance of costmap2DROS as

costmap_ = new costmap_2d::Costmap2DROS("costmap", tf_);

Once plugin_loader_.createInstance() is called in costmap2dROS pluginlib first loads costmap_2d plugins properly. However once it wants to load my_costmap::SpecifiedCostLayer, my_costmap_layer.so is found but I get a SIGABRT with the follwing error

ERROR: flag 'log_prefix' was defined more than once (in files 'src/base/logging.cc' and 'src/logging.cc').
my_package_2: /usr/include/boost/thread/pthread/recursive_mutex.hpp:104: boost::recursive_mutex::~recursive_mutex(): Assertion `!pthread_mutex_destroy(&m)' failed.

Any idea?

I am trying to use ros::pluginlib to load a plugin called A_Plugin which has been registered to ROS Package System correctly. One thing to note is that A_Plugin depends on Opensplice DDS, and it need to link the DDS libraries "libddskernel.so" ,"libdcpsisocpp.so". In CmakeLists.txt file, I write like this:
add_library(A_Plugin
src/aplugin.cpp
)
target_link_libraries(A_Plugin
$ENV{OSPL_HOME}/lib/libddskernel.so
$ENV{OSPL_HOME}/lib/libdcpsisocpp.so
)
It can be registered to ROS package system correctly, but when I use pluginlib::ClassLoader to load A_plugin, I got the following errors:terminate called after throwing an instance of 'pluginlib::CreateClassException'what(): MultiLibraryClassLoader: Could not create object of class type test::A_Plugin as no factory exists for it. Make sure that the library exists and was explicitly loaded through MultiLibraryClassLoader::loadLibrary(). How can I solve this problem? Thanks!

We've encountered that there is a junk of memory per loaded plugin not cleaned up.
When running a minimal example with valgrind, we see the following output:

==11631== 152 bytes in 1 blocks are indirectly lost in loss record 6 of 8
==11631== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11631== by 0x528F670: class_loader::impl::AbstractMetaObjectBase::AbstractMetaObjectBase(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) (meta_object.cpp:56)
==11631== by 0x791766A: ???
==11631== by 0x79172FE: ???
==11631== by 0x791710A: ???
==11631== by 0x7916E49: ???
==11631== by 0x7916F33: ???
==11631== by 0x7916F49: ???
==11631== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==11631== by 0x40107CA: call_init (dl-init.c:30)
==11631== by 0x40107CA: _dl_init (dl-init.c:120)
==11631== by 0x40158E1: dl_open_worker (dl-open.c:575)
==11631== by 0x4010563: _dl_catch_error (dl-error.c:187)
==11631==
==11631== 267 (16 direct, 251 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 8
==11631== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11631== by 0x79170F4: ???
==11631== by 0x7916E49: ???
==11631== by 0x7916F33: ???
==11631== by 0x7916F49: ???
==11631== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==11631== by 0x40107CA: call_init (dl-init.c:30)
==11631== by 0x40107CA: _dl_init (dl-init.c:120)
==11631== by 0x40158E1: dl_open_worker (dl-open.c:575)
==11631== by 0x4010563: _dl_catch_error (dl-error.c:187)
==11631== by 0x4014DA8: _dl_open (dl-open.c:660)
==11631== by 0x6C78F08: dlopen_doit (dlopen.c:66)
==11631== by 0x4010563: _dl_catch_error (dl-error.c:187)

The original issue to this: ros2/rosbag2#23

fyi @Martin-Idel-SI

Right I'm debugging an issue in ROS Kinetic where pluginlib is failing to find/load my plugins. If it turns out to be an issue that could affect other users, I'll create an Issue/PR for it.

In the mean time, I've encountered a more direct issue: I am not seeing much output when the pluginlib fails to load a class. In particular, after setting ROS_LOGGER level to DEBUG, I ran into this DEBUG output which seems like it should be a ROS_ERROR_NAMED as it throws:

template<class T>
void ClassLoader<T>::loadLibraryForClass(const std::string & lookup_name)
/***************************************************************************/
{
  ClassMapIterator it = classes_available_.find(lookup_name);
  if (it == classes_available_.end()) {
    ROS_DEBUG_NAMED("pluginlib.ClassLoader", "Class %s has no mapping in classes_available_.",
      lookup_name.c_str());
    throw pluginlib::LibraryLoadException(getErrorStringForUnknownClass(lookup_name));
}

It is possible that the pluginlib::LibraryLoadException should be printing a more user-friendly error, but I am not seeing any output in my logfile after the DEBUG print, so that might actually be the core of the issue.

The latest shadow-fixed Kinetic Xenial release is still using pluginlib 1.10.3, even though there was just a sync and bloom says it should be 1.10.4 - why is that? I confirmed this both in Docker containers and locally. The Travis build cannot pass until the latest plugin lib is available.

Is there a simple boilerplate example of creating and using pluginlib in ROS2? I think this would help everyone in various ROS2 migrations. I know MoveIt! is full of pluginlib usage and we need more documentation on how to use it around ament.

I have little knowledge of this, but I'm pretty sure @dirk-thomas (or someone else) will know for sure if this is a bug or if I'm using pluginlib wrong.

In my implementation I cannot let pluginlib manage instance. The problem is that when I try to unload the library (as the documentation says I need to do manually), pluginlib finds that resolved_library_path_ is UNRESOLVED and refuses to call the internal unload routine. The plugin is therefore never unloaded.

From what I can tell, the line that set resolved_library_path_ was removed in e16b58d and doesn't appear to be set anywhere else.

As a simple test:

• create an unmanaged instance of a plugin
• delete the reference to said instance
• check if library is loaded with isClassLoaded (this should still be true)
• attempt to unload the nodelet using unloadLibraryForClass

This throws pluginlib::LibraryUnloadException because resolved_library_path_ == "UNRESOLVED"

Was there a change that isn't in the documentation or is this a bug?

Thanks in advance for any guidance anyone can provide.