ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Why is swri_transform_util failing to build in ROS 2 Dashing on the build farm?

asked 2019-11-11 14:05:10 -0500

I've released the marti_common repository into ROS 2 Dashing on the build farm, and most of the packages build fine, but swri_transform_util fails to build:

It seems to be failing when cmake is running because it is trying to compile a test program that links in "pthreads", which of course makes sense because that doesn't exist. swri_transform_util does use Boost::thread, and as far as I can tell, that is declared properly in its package.xml and CMakeLists.txt.

I can also build the deb myself from the ros2-testing source repository in a clean ros:dashing Docker container; in fact, here's a simple Dockerfile that does so:

FROM ros:dashing

RUN echo 'deb bionic main' >> /etc/apt/sources.list.d/ros2-latest.list
RUN echo 'deb-src bionic main' >> /etc/apt/sources.list.d/ros2-latest.list

RUN apt-get update && \
    apt-get install -y apt-src && \
    apt-src install ros-dashing-swri-transform-util && \
    apt-src build ros-dashing-swri-transform-util && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

This builds without error, and I can't figure out what the build farm is doing differently that is causing it to fail. In fact, the output seems the same; inside the Docker image, /ros-dashing-swri-transform-util-3.0.1/obj-x86_64-linux-gnu/CMakeFiles/CMakeError.log contains the same pthreads-related error messages that I see on the build farm, but for some reason that did not cause apt-src to exit and flag the build as a failure.

Does anybody have any idea what's going wrong here? Thanks in advance!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-11-11 14:20:06 -0500

Dirk Thomas gravatar image

The actual error message you are looking for is way further up in the console output:

00:05:36.611 CMake Error at CMakeLists.txt:90 (find_package):
00:05:36.611   By not providing "Findament_cmake_gtest.cmake" in CMAKE_MODULE_PATH this
00:05:36.611   project has asked CMake to find a package configuration file provided by
00:05:36.611   "ament_cmake_gtest", but CMake did not find one.
00:05:36.611   Could not find a package configuration file provided by "ament_cmake_gtest"
00:05:36.611   with any of the following names:
00:05:36.611     ament_cmake_gtestConfig.cmake
00:05:36.611     ament_cmake_gtest-config.cmake
00:05:36.611   Add the installation prefix of "ament_cmake_gtest" to CMAKE_PREFIX_PATH or
00:05:36.611   set "ament_cmake_gtest_DIR" to a directory containing one of the above
00:05:36.611   files.  If "ament_cmake_gtest" provides a separate development package or
00:05:36.611   SDK, be sure it has been installed.
00:05:36.613 -- Configuring incomplete, errors occurred!

The reason is that the swri_transform_util package tries to use ament_cmake_gtest( but doesn't declare a (test) dependency on it in the package manifest.

edit flag offensive delete link more


Ah, oops! Thanks for catching that. I should just remove that for the moment since I don't have the tests working anyway. Although, do you know why that would cause it to fail on the build farm but not in a standalone container?

preed gravatar image preed  ( 2019-11-11 14:24:51 -0500 )edit

It depends on how your underlay was build. If it uses isolation (each package having a separate directory under install) it would have failed locally to. If your underlay uses a merged install then depending on any other package will pull in the same base path and ament_cmake_gtest can be found in the same location.

Dirk Thomas gravatar image Dirk Thomas  ( 2019-11-11 14:26:56 -0500 )edit

Question Tools

1 follower


Asked: 2019-11-11 14:05:10 -0500

Seen: 228 times

Last updated: Nov 11 '19