Posted by @cwrx777:
--- stderr: rmf_traffic_ros2
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find LibUUID (missing: LibUUID_LIBRARY LibUUID_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
cmake/FindLibUUID.cmake:69 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:29 (find_package)
---
Failed <<< rmf_traffic_ros2 [1.79s, exited with code 1]
Posted by @mxgrey:
I know it can be tricky to distinguish between discussions and issues, but the last two discussions that you’ve opened would be more appropriate to post as issues since you’re reporting something malfunctioning in the software. If that’s reported as an issue then we can Close it after we’ve resolved the issue, whereas a discussion can’t be closed. At best I can delete these discussions after they’re resolved and no longer relevant.
But that’s for future reference. For this specific issue, I’d like to check whether you are using the branch in this PR. If you use that branch and use rosdep then I believe this problem should be solved. Let us know if that branch does not resolve this issue.
Posted by @cwrx777:
hi @mxgrey
The issue in RHEL still occurred even if the key in package.xml has been changed to uuid. the LibUUID in the error message is from the cmakelist file.
Posted by @mxgrey:
The error message indicates that it can’t find the libuuid package on your system. That would mean one of two things:
- The uuid library is not installed on your system, or
- The find-module is not implemented correctly
We need to eliminate possibility (1) before we give too much consideration to possibility (2).
The find-module that we’re using for uuid was lifted directly from cmake’s official source code (it’s part of a very new version of cmake that isn’t available on our supported distros yet so we’re just copying their BSD-licensed source code). Since it’s the official cmake find-module it seems unlikely that it would be implemented incorrectly, but I certainly can’t rule it out.
Can you ensure that you have libuuid installed on your system before we begin investigating the find-module?
Edited by @mxgrey at 2022-09-17T15:16:19Z
Posted by @cwrx777:
Hi @mxgrey
$ dnf list installed | grep uuid
libuuid.x86_64 2.32.1-35.el8 @rhel-8-for-x86_64-baseos-rpms
Posted by @mxgrey:
In that case the only thing I can think of is to add CMAKE_FIND_DEBUG_MODE around the search for libuuid in rmf_traffic_ros2 assuming you have a version of cmake that’s 3.17 or greater.
I don’t have access to redhat myself so I can’t debug the find-module behavior. I’ve looked over the file and I’ve looked at how redhat packages libuuid, and the find-module looks perfectly reasonable to me, so if there’s an error in it then it must be something very subtle.
Posted by @mxgrey:
Could you check your filesystem and see if any files with the pattern
/usr/lib64/libuuid*
exist?
Edited by @mxgrey at 2022-09-18T18:00:15Z
Posted by @cwrx777:
$ ls /usr/lib64/libuuid* -al
lrwxrwxrwx. 1 root root 16 Mar 8 2022 /usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x. 1 root root 33464 Mar 8 2022 /usr/lib64/libuuid.so.1.3.0
Posted by @cwrx777:
I modified the rmf_traffic_ros2\CMakeLists.txt:
set(CMAKE_FIND_DEBUG_MODE TRUE)
find_package(LibUUID REQUIRED)
set(CMAKE_FIND_DEBUG_MODE FALSE)
and rmf_traffic_ros2\cmake\FindLibUUID.cmake:
set(CMAKE_FIND_DEBUG_MODE TRUE)
find_library(LibUUID_LIBRARY
NAMES uuid
)
set(CMAKE_FIND_DEBUG_MODE FALSE)
set(CMAKE_FIND_DEBUG_MODE TRUE)
find_path(LibUUID_INCLUDE_DIR
NAMES uuid/uuid.h
)
set(CMAKE_FIND_DEBUG_MODE FALSE)
Build Output:
gist
Edited by @cwrx777 at 2022-09-19T04:51:56Z
Posted by @mxgrey:
Thanks for the outputs, I believe I know what the issue is now. However, I would appreciate if you could edit your reply by moving the very long output into a public https://gist.github.com and link to the gist in your comment. As it currently is, it’s very difficult to read the discussion with the very long wall of text. I generally recommend this approach for any copy/paste content that’s longer than ~20 lines.
Now for the actual issue, are you certain that you’ve checked out this PR and re-run rosdep? The dependency key in the package.xml for that PR should have rosdep install libuuid-devel on your system, but it looks like you only have libuuid installed, which is not enough for cmake to find and link against.
I suggest checking out that PR and running rosdep. If that still fails then you can try manually installing libuuid-devel and then try to build again. But rosdep ought to work, so let us know if it doesn’t for some reason.
Posted by @cwrx777:
Hi @mxgrey ,
Running rosdep did not highlight anything about libuuid-devel.
$ rosdep install --from-paths src --ignore-src --rosdistro=humble -y
ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies:
ros_gz_bridge: No definition of [ignition-transport11] for OS [rhel]
ros_gz_sim_demos: No definition of [ignition-gazebo6] for OS [rhel]
rmf_robot_sim_gz_plugins: No definition of [ignition-fortress] for OS [rhel]
ros_gz_image: No definition of [ignition-transport11] for OS [rhel]
ros_gz_sim: No definition of [ignition-math6] for OS [rhel]
rmf_building_sim_gz_plugins: No definition of [ignition-fortress] for OS [rhel]
rmf_demos_panel: No definition of [python3-websockets] for OS [rhel]
rmf_demos_gz: No definition of [ignition-fortress] for OS [rhel]
rmf_demos_bridges: No definition of [python3-flask-socketio] for OS [rhel]
then I installed libuuid-devel manually:
sudo dnf install libuuid-devel
then after that:
$ ls -all /usr/lib64/libuuid*
lrwxrwxrwx. 1 root root 16 Mar 8 2022 /usr/lib64/libuuid.so -> libuuid.so.1.3.0
lrwxrwxrwx. 1 root root 16 Mar 8 2022 /usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x. 1 root root 33464 Mar 8 2022 /usr/lib64/libuuid.so.1.3.0
colcon build output:
Starting >>> rmf_traffic_ros2
--- stderr: rmf_traffic_ros2
ld.lld: error: undefined symbol: std::filesystem::__cxx11::path::_M_split_cmpts()
>>> referenced by test_ParticipantRegistry.cpp
>>> CMakeFiles/test_rmf_traffic_ros2.dir/test/unit/test_ParticipantRegistry.cpp.o:(C_A_T_C_H_T_E_S_T_9())
ld.lld: error: undefined symbol: std::filesystem::status(std::filesystem::__cxx11::path const&)
>>> referenced by test_ParticipantRegistry.cpp
>>> CMakeFiles/test_rmf_traffic_ros2.dir/test/unit/test_ParticipantRegistry.cpp.o:(C_A_T_C_H_T_E_S_T_9())
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/test_rmf_traffic_ros2.dir/build.make:276: test_rmf_traffic_ros2] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:319: CMakeFiles/test_rmf_traffic_ros2.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
gmake: *** [Makefile:146: all] Error 2
---
Failed <<< rmf_traffic_ros2 [0.78s, exited with code 2]
Posted by @mxgrey:
For the rosdep issue, it seems that quite a few dependencies of the “complete” RMF suite are not available (yet) on RedHat, especially dependencies related to simulation. Because of those missing dependencies, rosdep is not installing any of the dependencies, preferring to be cautious.
You should be able to tell rosdep to disregard those errors by adding a -r flag like this:
$ rosdep install --from-paths src --ignore-src --rosdistro=humble -y -r
Doing that should make it so you don’t need to manually install libuuid-devel in the future.
The linking error is a more complex issue. I believe the cause is the clang-libcxx mixin for colcon, but I’ll need to consult with my team about how we want to address that.
Posted by @mxgrey:
Can I check what build instructions you were using to build your colcon workspace? The issue could either be from using clang-libcxx or it could be that RedHat’s version of libstdc++ requires some extra linking in the build scripts for std::filesystem.
Posted by @cwrx777:
I built using this instructions.
Will RMF be available as binary installation for RHEL 8?