Closed Volksfest closed 1 year ago
olivier-stasse
commented
1 year ago Dear @Volksfest,
not sure it helps, but on a containerized (qemu) 22.04 LTS with ros2_control at commit #8141212 and ros2_controller at commit #ca38c06, libjoint_trajectory_controller.so has no dependency on libmock_components.so (rolling).
I did not check on humble.
If you recompile from the the master branch, it will be better to switch to rolling and recompile ros2_control.
bmagyar
commented
1 year ago These type of overly generous linking and includes were often complains towards rosbuild. This was back in 2013. Catkin and ament should not produce these problems anymore but your evidence suggests the opposite.
Are you using colcon or the cmake cli for building? I don't think I ever tried the cmake cli on ROS 2 but it was possible and some people preferred that for fine tuning things in ROS 1.
From: Olivier Stasse @.> Sent: Saturday, September 30, 2023 8:23:40 PM To: ros-controls/ros2_control @.> Cc: Subscribed @.***> Subject: Re: [ros-controls/ros2_control] hardware_interface dependency yields to linking to unnecessary libraries yielding to class_loader warnings (Issue #1113)
Dear @Volksfesthttps://github.com/Volksfest, not sure it helps, but on a containerized (qemu) 22.04 LTS with ros2_control at commit #8141212 and ros2_controller at commit #ca38c06, libjoint_trajectory_controller.so has no dependency on libmock_components.so (rolling).
I did not check on humble.
If you recompile from the the master branch, it will be better to switch to rolling and recompile ros2_control.
— Reply to this email directly, view it on GitHubhttps://github.com/ros-controls/ros2_control/issues/1113#issuecomment-1741841877, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA24PYI52AT7ZINDMCVV6I3X5BWTZANCNFSM6AAAAAA4ZLOZXY. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Volksfest
commented
1 year ago @bmagyar I am not sure what you mean with cmake cli. Just the cmake command or does it include to avoid ament? I also tried to build the package just with cmake without colcon with no differences. I didn't try to get rid of ament and adding all the dependencies on my own as this is a bit cumbersome and even if it worked a bad solution.
But interestingly, I found the reason: The problem seems to be using clang. With gcc the dependencies are as expected:
$ ldd libcartesian_controller_base.so
linux-vdso.so.1 (0x00007ffd7c5c8000)
libkdl_parser.so => /opt/ros/humble/lib/libkdl_parser.so (0x00007f496966b000)
liburdf.so => /opt/ros/humble/lib/liburdf.so (0x00007f496962f000)
libgeometry_msgs__rosidl_typesupport_cpp.so => /opt/ros/humble/lib/libgeometry_msgs__rosidl_typesupport_cpp.so (0x00007f4969624000)
librmw.so => /opt/ros/humble/lib/librmw.so (0x00007f4969618000)
libconsole_bridge.so.1.0 => /lib/x86_64-linux-gnu/libconsole_bridge.so.1.0 (0x00007f49695ee000)
libclass_loader.so => /opt/ros/humble/lib/libclass_loader.so (0x00007f49695d9000)
libtinyxml2.so.9 => /lib/x86_64-linux-gnu/libtinyxml2.so.9 (0x00007f49695c1000)
librcl.so => /opt/ros/humble/lib/librcl.so (0x00007f4969583000)
libtracetools.so => /opt/ros/humble/lib/libtracetools.so (0x00007f496957e000)
librcpputils.so => /opt/ros/humble/lib/librcpputils.so (0x00007f4969570000)
librcutils.so => /opt/ros/humble/lib/librcutils.so (0x00007f4969558000)
librclcpp_lifecycle.so => /opt/ros/humble/lib/librclcpp_lifecycle.so (0x00007f4969515000)
libcontroller_interface.so => /opt/ros/humble/lib/libcontroller_interface.so (0x00007f4969507000)
liborocos-kdl.so.1.5 => /lib/x86_64-linux-gnu/liborocos-kdl.so.1.5 (0x00007f4969144000)
librclcpp.so => /opt/ros/humble/lib/librclcpp.so (0x00007f4968f50000)
libament_index_cpp.so => /opt/ros/humble/lib/libament_index_cpp.so (0x00007f49694fc000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4968c00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f49694da000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4968800000)
librosidl_typesupport_cpp.so => /opt/ros/humble/lib/librosidl_typesupport_cpp.so (0x00007f49694d4000)
librcl_yaml_param_parser.so => /opt/ros/humble/lib/librcl_yaml_param_parser.so (0x00007f49694c8000)
librmw_implementation.so => /opt/ros/humble/lib/librmw_implementation.so (0x00007f49694bb000)
librcl_logging_spdlog.so => /opt/ros/humble/lib/librcl_logging_spdlog.so (0x00007f4968f49000)
librcl_interfaces__rosidl_typesupport_c.so => /opt/ros/humble/lib/librcl_interfaces__rosidl_typesupport_c.so (0x00007f4968f40000)
librcl_interfaces__rosidl_generator_c.so => /opt/ros/humble/lib/librcl_interfaces__rosidl_generator_c.so (0x00007f4968f24000)
librosidl_runtime_c.so => /opt/ros/humble/lib/librosidl_runtime_c.so (0x00007f4968f19000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4969676000)
librcl_lifecycle.so => /opt/ros/humble/lib/librcl_lifecycle.so (0x00007f4968f0f000)
liblifecycle_msgs__rosidl_typesupport_cpp.so => /opt/ros/humble/lib/liblifecycle_msgs__rosidl_typesupport_cpp.so (0x00007f4968f07000)
liblifecycle_msgs__rosidl_typesupport_c.so => /opt/ros/humble/lib/liblifecycle_msgs__rosidl_typesupport_c.so (0x00007f4968f00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4968b19000)
liblibstatistics_collector.so => /opt/ros/humble/lib/liblibstatistics_collector.so (0x00007f4968ef9000)
librcl_interfaces__rosidl_typesupport_cpp.so => /opt/ros/humble/lib/librcl_interfaces__rosidl_typesupport_cpp.so (0x00007f4968eee000)
librosgraph_msgs__rosidl_typesupport_cpp.so => /opt/ros/humble/lib/librosgraph_msgs__rosidl_typesupport_cpp.so (0x00007f4968ee9000)
libstatistics_msgs__rosidl_typesupport_cpp.so => /opt/ros/humble/lib/libstatistics_msgs__rosidl_typesupport_cpp.so (0x00007f4968ee4000)
librcl_logging_interface.so => /opt/ros/humble/lib/librcl_logging_interface.so (0x00007f4968edf000)
libyaml.so => /opt/ros/humble/lib/libyaml.so (0x00007f4968ebd000)
libspdlog.so.1 => /lib/x86_64-linux-gnu/libspdlog.so.1 (0x00007f4968e42000)
librosidl_typesupport_c.so => /opt/ros/humble/lib/librosidl_typesupport_c.so (0x00007f4968e3c000)
libbuiltin_interfaces__rosidl_generator_c.so => /opt/ros/humble/lib/libbuiltin_interfaces__rosidl_generator_c.so (0x00007f4968e37000)
liblifecycle_msgs__rosidl_generator_c.so => /opt/ros/humble/lib/liblifecycle_msgs__rosidl_generator_c.so (0x00007f4968b09000)
libfmt.so.8 => /lib/x86_64-linux-gnu/libfmt.so.8 (0x00007f4968ae8000)So I think in general, it is not a good idea to use clang with ros. Later problems I got with building stuff myself with clang also resulted in failure whereas it worked well with gcc. It is a bit unfortunated to rely so much on a specific compiler but this is not an issue of ros-controls. Thanks for your advices.
aosmw
commented
1 year ago I know this is closed but I also have this issue and wanted to get to the bottom of it.
IMHO It was resolved here, https://github.com/ros-controls/ros2_control/commit/727297efa800d7c1dfdc59352c0f7645c779ea36, when ament_export_libraries stopped exporting mock_components and fake_components along with hardware_interface.
This means that find_package(hardware_interface REQUIRED) no longer gives a hardware_interface_LIBRARIES variable that has the mock_components and/or fake_components libraries appended to it.
bmagyar
commented
1 year ago And you verified it by building successfully w clang?
aosmw
commented
1 year ago No I did not verify it by building with clang.
I am using gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 and cmake version 3.22.1
At this stage I have only tweaked a local copy of a humble snapshot as I come to grips with ros2_control.
I am currently in the throws of writing a SystemInterface for our robot.
I have only verified it for my usage and have not run any ros2_control tests to assess the impact of the change below on other systems.
diff --git a/src/ros-controls/ros2_control/hardware_interface/CMakeLists.txt b/src/ros-controls/ros2_control/hardware_interface/CMakeLists.txt
index 2fb3164..9335dc6 100644
--- a/src/ros-controls/ros2_control/hardware_interface/CMakeLists.txt
+++ b/src/ros-controls/ros2_control/hardware_interface/CMakeLists.txt
@@ -183,8 +183,6 @@ ament_export_include_directories(
include
)
ament_export_libraries(
- fake_components
- mock_components
${PROJECT_NAME}
)
ament_export_dependencies(${THIS_PACKAGE_INCLUDE_DEPENDS})
adv4ncr
commented
11 months ago I ran into exactly the same issue on humble using clang instead of gcc.
The patch suggested by @aosmw does not fix the issue of the namespace collision with mock_components::GenericSystem when using clang.
adv4ncr
commented
11 months ago I ran into exactly the same issue on humble using clang instead of gcc.
The patch suggested by @aosmw fixes the issue of the namespace collision with mock_components::GenericSystem when using clang.
So, first of all, the system: Ubuntu 22.04.03 LTS jammy ROS2 humble ros2_control via apt (http://packages.ros.org/ros2/ubuntu jammy main)
To the story: It started with building cartesian_joint_controller (https://github.com/fzi-forschungszentrum-informatik/cartesian_controllers/tree/ros2). Trying to use it broke and, honestly, I didn't check why. Simple because I started to check the logs and wanted to solve the problem step-by-step and found a rather annoying warning:
I assume it is not that critical as it probably overwrite the same thing but it still hints to something which went wrong... So I start investigating the ominous linkage to mock_components or actually the library libmock_components.so
First checked the build controller (or actually its depended base):
Look at the highlighted line with the arrow and the the annoying linkage to the libmock_components.so . This so far isn't surprising with the given warning.
I continued with checking the "apt installed" joint_trajectory_controller to have a reference:
Looks a lot smaller and especially without libmock_components.so So this got more interesting of course by building the joint_trajectory_controller myself (https://github.com/ros-controls/ros2_controllers/tree/humble)
And there it is again. So, not only the libmock_components.so is "unnecessary" but a whole lot of libraries more. I tried to narrow the reason down with a small example:
CMakeLists.txt:
The resulting warning message (the second library already, just don't waste the time to read everything; i just posted it for completeness):
The resulting linkage:
So yeah, I fast forwarded a bit and narrowed down to libhardware_interface.so already. At least ament does weird things with hardware_interface_LIBRARIES The dependencies would be
control_msgs;lifecycle_msgs;pluginlib;rclcpp_lifecycle;rcpputils;rcutils;tinyxml2_vendor;TinyXML2and I don't think that any of them yields to the libmock_components.so linkage.So now the question? Where does it come from when building on my own? As hardware_interface is part of this repository, I decided to ask here first. I don't get the resulting linked libraries as hardware_interface itself does not seem to need them:
I also have no clue how to prohibit it. Do I (or actually other people as I just want to build other repositories...) miss any build options? (in https://github.com/fzi-forschungszentrum-informatik/cartesian_controllers/blob/ros2/cartesian_controller_base/CMakeLists.txt)? The best idea I have is to set everything myself up (target_link_library, target_include_directory...) but this shouldn't be the solution for the problem?!?
Another problem source may be using the ros2_control package from apt. I would highly avoid building ros2_control myself as also other apt packages depend on it... and actually the apt package should have a correct/stable dependency to rely on? So, what would you suggest? Do I really rely on building it (and the rest) myself? Should I just ignore it? Maybe, there is a really simple solution which I miss?
PS: I had to shorten the ldd dumps a bit as there were too much characters for the issue :(