Linker error with Rviz2 plugin: undefined symbol: tf2::fromMsg

[FelipeGdM]

Bug report

Required Info:

• Operating System:
  • Ubuntu 22.04
• Installation type:
  • Binaries
• Version or commit hash:
  • 0.25.5-1jammy.20231117.203705
• DDS implementation:
  • Humble default
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

• Compile the project CARLA ROS bridge
• Load the rviz_carla_plugin
• Publish any message from CARLA

Expected behavior

Rviz2 should load the plugin and process the messages as intended

Actual behavior

Rviz2 crashes with the message:

rviz2: symbol lookup error: /home/felipe/Documents/Github/carla_ws/install/rviz_carla_plugin/lib/librviz_carla_plugin.so: undefined symbol: _ZN3tf27fromMsgERKN13geometry_msgs3msg11Quaternion_ISaIvEEERNS_10QuaternionE

Additional information

There is a lot of stuff going on in this setup, so it wasn't easy to pin point the problem within geometry2.

The evidence that I collected so far, in the file tf2/impl/utils.h, we have the declaration of the prototype fromMsg function.

geometry2/tf2/include/tf2/impl/utils.h

Line 29 in b9b06ec

void fromMsg(const geometry_msgs::msg::Quaternion & in, tf2::Quaternion & out);

This declaration creates an undefined symbol in the plugin dynamic object.

$ objdump -tC ./build/rviz_carla_plugin/CMakeFiles/rviz_carla_plugin.dir/src/carla_control_panel_ROS2.cpp.o | grep fromMsg
0000000000000000         *UND*  0000000000000000 tf2::fromMsg(geometry_msgs::msg::Quaternion_<std::allocator<void> > const&, tf2::Quaternion&)

When rviz2 tries to execute the plugin's code, it stumbles upon an undefined symbol and then crashes.

As described here carla-simulator/ros-bridge#711, a quick and dirt solution is to add a bogus fromMsg declaration

namespace tf2{
  void fromMsg(const geometry_msgs::msg::Quaternion & in, tf2::Quaternion & out){
    (void)(in);
    (void)(out);
  };
}

I tried to include tf2/convert.h and call the template version of fromMsg, but I got a different error

Code in rviz2 plugin

namespace tf2{
  void fromMsg(const geometry_msgs::msg::Quaternion & in, tf2::Quaternion & out){
    fromMsg(in, out);
  };
}

Terminal

rviz2 -d src/ros-bridge/carla_ad_demo/config/carla_ad_demo_ros2
.rviz
[INFO] [1701717747.297741667] [rviz2]: Stereo is NOT SUPPORTED
[INFO] [1701717747.297844785] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[INFO] [1701717747.323646353] [rviz2]: Stereo is NOT SUPPORTED
fish: Job 1, 'rviz2 -d src/ros-bridge/carla_a…' terminated by signal SIGSEGV (Address boundary error)

I'm not sure why the prototype declaration of the fromMsg is needed, so my suggestion would be the simple removal of that declaration in that file.

It may be related to #242, but I'm not entirely sure

[clalancette]

As described here carla-simulator/ros-bridge#711, a quick and dirt solution is to add a bogus fromMsg declaration

Yes, you need to have this definition. It is generally provided by tf2_geometry_msgs here:

geometry2/tf2_geometry_msgs/include/tf2_geometry_msgs/tf2_geometry_msgs.hpp

Lines 933 to 938 in b9b06ec

	inline
	void fromMsg(const geometry_msgs::msg::Quaternion & in, tf2::Quaternion & out)
	{
	// w at the end in the constructor
	out = tf2::Quaternion(in.x, in.y, in.z, in.w);
	}

. So another way to fix this would be to link with tf2_geometry_msgs.

[mikeferguson]

So, I think it's more involved than just linking against tf2_geometry_msgs - you need to include "tf2_geometry_msgs/tf2_geometry_msgs.hpp" BEFORE "tf2/utils.hpp" per discussion here: #485.

I have no idea why, but I also just recently hit this on https://github.com/mikeferguson/graceful_controller - where I haven't changed any code since March and I'm now having this missing symbol issue. I presume some header I included must have previously included the tf2_geometry_msgs header file, and now no longer does.

In my case the issue was:

• Include <tf2/utils.h>
• Use tf2::getYaw<geometry_msgs::msg::Quaternion>
• This in turn calls tf2::impl::toQuaternion(geometry_msgs::msg::Quaternion)
• Which then calls fromMsg(geometry_msgs::msg::Quaternion, tf2::Quaternion) - which is in tf2_geometry_msgs.hpp, which I was not directly including

[clalancette]

I have no idea why, but I also just recently hit this on https://github.com/mikeferguson/graceful_controller - where I haven't changed any code since March and I'm now having this missing symbol issue. I presume some header I included must have previously included the tf2_geometry_msgs header file, and now no longer does.

Which release are you testing against?

[mikeferguson]

Actually, I just realized my build failure isn't actually new - I only hit this build failure when building RelWithDebugInfo (mikeferguson/graceful_controller#52) - which makes it even stranger.

UPDATE: including tf2_geometry_msgs/tf2_geometry_msgs.hpp BEFORE tf2/utils.h DOES fix my build issue even when using RelWithDebugInfo - even though the PR above seems to indicate that it shouldn't still be an issue

[mikeferguson]

Which release are you testing against?

I'm on Iron, latest debs 0.31.5

[FelipeGdM]

@clalancette @mikeferguson thank you for your reply!

I can confirm what @mikeferguson said that just linking tf2_geometry_msgs is not enough to solve the problem, it is also needed to add the #include <tf2_geometry_msgs/tf2_geometry_msgs.hpp> statement

My guess for this problem is that something changed within tf2 dependencies that broke downstream packages. I faced a similar issue with dependencies that suddenly disappear with tf2_eigen carla-simulator/ros-bridge#709

If tf2/impl/utils.hpp depends on the declaration of this function on tf2_geometry_msgs/tf2_geometry_msgs.hpp, wouldn't it be better to directly include this header in utils.hpp?

[clalancette]

If tf2/impl/utils.hpp depends on the declaration of this function on tf2_geometry_msgs/tf2_geometry_msgs.hpp, wouldn't it be better to directly include this header in utils.hpp?

In theory, yes. The problem is that we can't do that, as it creates a circular dependency between tf2_geometry_msgs and tf2, which we really don't want to do.

Probably the right solution is to redesign this API, something along the lines of #427 . But it is a very large change, and we haven't been able to get it in yet. Also, it will cause some short-term pain, but will be better in the long-term.

[FelipeGdM]

The problem is that we can't do that, as it creates a circular dependency between tf2_geometry_msgs and tf2, which we really don't want to do.

Sounds reasonable, classic project growing pains...

I will close this one as the original problem was solved and a refactor is already in the horizon. If someone else faces the same problem, I hope this discussion may be useful

Thank you very much for your support!