symbol lookup error: undefined symbol _ZN6rclcpp*

[tommy-erko]

Bug report

Required Info:

• Operating System:
  • Ubuntu 22.04.1 LTS
• Installation type:
  • apt binaries
• Version or commit hash:
  • ros-rolling-rclcpp/jammy 17.1.0-1jammy.20221108.012818 amd64 (latest)
• DDS implementation:
  • Cyclone or Fast (same behavior)
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

Not included now as the project is internal. I can try to create simpler example that will behave similarly.

Expected behavior

Several rclcpp nodes start up and are ready to control a simulated robot (in Ignition Gazebo).

Actual behavior

Since the latest ROS2 rolling update, once we run multiple rclcpp nodes, we get a "symbol lookup error" from each of them. There are these types:

[node_name_a-5] /opt/ros/rolling/lib/package_a/node_name_a: symbol lookup error: /opt/ros/rolling/lib/package_a/node_name_a: undefined symbol: _ZN6rclcpp11ServiceBaseD2Ev

[node_name_b-14] /opt/ros/rolling/lib/package_b/node_name_b: symbol lookup error: /opt/ros/rolling/lib/package_b/node_name_b: undefined symbol: _ZN6rclcpp10ClientBaseD2Ev

[node_name_c-17] /opt/ros/rolling/lib/package_c/node_name_c: symbol lookup error: /opt/ros/rolling/lib/package_c/node_name_c: undefined symbol: _ZN6rclcpp12experimental28SubscriptionIntraProcessBaseD2Ev

In a simplified case, we launch only one our node and Navigation2 stack and the node dies the same. (with the _ZN6rclcpp10ClientBaseD2Ev)

Additional information

Our project runs on ros-rolling. This issues started to appear with the latest rolling update (since 19.11.22). If we start the

I know the information is rough, but I am not able to disclose any of the code. I would firstly like to get some feedback where this might come from, whether it might be our issue, or inform you that something like this started to happen. Either is appreciated.

[clalancette]

Have you rebuilt your stack since the update? Since we don't guarantee ABI compatibility on Rolling, it is possible that the ABI changed.

[tommy-erko]

Thank you for your reply. We have done so, but if it seems like a likely source, I will do that again and with closer attention.

[tommy-erko]

Sorry for false alarm, it seems our stack rebuild did not work as supposed to. So if anyone encounters something similar, this was caused by part of the components built against older ROS2.