New packages for Crystal 2019-01-31

ROS ROS General
,
1

I’m happy to announce the latest updates for ROS 2 Crystal Clemmys.

Package Updates for crystal

Added Packages [7]:

Updated Packages [8]:

  • ros-crystal-librealsense2: 2.16.5-1 → 2.16.5-2
  • ros-crystal-librealsense2-dbgsym: 2.16.5-1 → 2.16.5-2
  • ros-crystal-object-analytics-msgs: 0.5.2-0 → 0.5.3-0
  • ros-crystal-object-analytics-msgs-dbgsym: 0.5.2-0 → 0.5.3-0
  • ros-crystal-object-analytics-node: 0.5.2-0 → 0.5.3-0
  • ros-crystal-object-analytics-node-dbgsym: 0.5.2-0 → 0.5.3-0
  • ros-crystal-object-analytics-rviz: 0.5.2-0 → 0.5.3-0
  • ros-crystal-object-analytics-rviz-dbgsym: 0.5.2-0 → 0.5.3-0

Removed Packages [0]:

Thanks to all ROS maintainers who make packages available to the ROS community. The above list of packages was made possible by the work of the following maintainers:

  • AWS RoboMaker
  • Bence Magyar
  • Chris Ye
  • Daniel Stonier
  • Ralph Lange
  • Sergey Dorodnicov
2 Likes
2

I’m sorry, I made a copy+paste error in the CMakeLists.txt of fmi_adapter in this release: The shared library (libfmi_adapter.so) is installed in crystal/lib/fmi_adapter (just as the node executable) rather than crystal/lib. Meanwhile, it is fixed: Fixed install target location of shared library. · boschresearch/fmi_adapter@936c52f · GitHub

@nuclearsandwich This type of error is detected neither by local unit tests nor on the build farm? What do you think, should I open an issue on GitHub - ros-infrastructure/ros_buildfarm: ROS buildfarm based on Docker for that?

3

The unit tests can’t detect the bug because they use the executable from the CMAKE_BINARY_DIR and that binary uses a full RPATH to the library.

When you are installing the executable CMake is clearing full RPATH to instead rely on LD_LIBRARY_PATH. And since the path <prefix>/lib/fmi_adapter is not listed in that environment variable it will fail to find the library.

As a consequence also the ros_buildfarm has no way to check for this.

If you would like add tests covering your installed packages you could create a separate package test_fmi_adapter which depends on fmi_adapter and contains tests which ensure that the installed package fmi_adapter is working as desired. (In the release process using bloom you usually want to skip the test_fmi_adapter package from being released to avoid a Debian package being created for it. This can be configured in the release repository.)

2 Likes
4

Thank you for the detailed explanation, @dirk-thomas. With it, I was able to reproduce the bug from a second package (the existing fmi_adapter_examples package), but only when not using colcon’s --symlink-install option. (Many thanks to @karsten for the hint on this option.)

1 Like