ROS 2 tests failing to find Gazebo plugins on ROS farm CI

[chapulina]

The elevator and harness tests are failing in the ROS farm CI, but not locally or on the OSRF farm. It's a runtime failure because the Gazebo plugins which they inherit from cannot be found:

libHarnessPlugin.so: cannot open shared object file: No such file or directory

---

Note that GazeboRosCamera also inherits from a plugin shipped with Gazebo, but the camera tests are not running in the ROS farm because of the lack of GPU support.

gazebo_ros_pkgs/gazebo_plugins/include/gazebo_plugins/gazebo_ros_camera.hpp

Line 58 in 566fde1

class GazeboRosCamera : public gazebo::CameraPlugin

---

These Gazebo plugins are part of gazebo9-plugin-base , which should be pulled with libgazebo9-dev. I assume this is being properly installed through the libgazebo9-dev rosdep key.

What could be happening here? Are the plugins being installed, but in a place where Gazebo can't find them? I believe they must be in LD_LIBRARY_PATH to be loaded correctly.

Any help is appreciated, @j-rivero @nuclearsandwich

[nuclearsandwich]

I took a look at this following the dependency chain to figure out why the package should be installed.

• gazebo_plugins (the package with the failing test) -[exec_depend]-> gazebo_dev
• gazebo_dev -[exec_depend]-> gazebo9
• gazebo_dev -[build_export_depend]-> libgazebo9-dev.
• libgazebo9-dev -[Depend:]-> gazebo9-plugin-base

From the build logs it looks like gazebo9-plugin-base is installed in the devel job images (both build and install, and build and test)

Does the GAZEBO_PLUGIN_PATH need to be set when using Gazebo from the upstream Ubuntu repositories and is there a setup script in gazebo_dev taking care of that?

---

You can reproduce the ROS buildfarm environment with the command

generate_devel_script.py https://raw.githubusercontent.com/ros2/ros_buildfarm_config/ros2/index.yaml dashing default gazebo_ros_pkgs ubuntu bionic amd64 > run.sh

Depending on your workflow, you can either remove the --rm option from the final container and then restart it (sending a SIGSTOP to the python3 process that will run the container's default task) and docker-exec into it in order to reproduce and test or use the base image that the script generates to create your own reproduction with docker-run.

[chapulina]

Fixed by #974, thanks for all the help, @nuclearsandwich !

[traversaro]

I can't confirm this in a vanilla build of ROS 2 (hence I will not open a new issue) but I guess the macOS part of this issue occurred again on modern macOS systems due to DYLD_LIBRARY_PATH sanification, see RoboStack/ros-humble#185 .