| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Hi, I always get this error:
/usr/bin/ld: CMakeFiles/mechanum_steering_node.dir/__/drive/interface/SocketCAN.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
When I add Thread as REQUIRED_COMPONENTS and target_link_libraries it works again for this specific package. How can I solve this globally?
This happened because all ROS packages link against the libc version roscpp was linked against. You have to recompile roscpp and cpp_common, afterwards try again. If you use the official binaries for Debian/Ubuntu by Open Robotics, this probably isn't the same issue, if you think so, please contact the maintainers. As I use ROS on Archlinux simply had to recompile rostime, cpp-common and roscpp, now everything works again. If the binaries on Arch are linking to wrong libc and I didn't already ran into it, please contact me.
I think that's something that can appear on every Linux Distribution. The libc change, and ROS packages use roscpp to link against the libc, so if roscpp links against the old version, ROS packages will try to link against the old version if you not specify needed libs manually in cmake.
On Debian/Ubuntu it's not that common to build ROS from source. On-top of that, glibc changes are relatively rare on these platforms, and if there are changes, they are guaranteed to be bw-compatible wrt ABI. I'm not 100% certain, but I would be really surprised if I would run into the error message that you posted on those platforms.
Rebuilding a workspace is something that is done on every OS/platform, but what you experienced is something I expect users on non-Debian/Fedora (and derived) platforms to run into sooner.
Hence the request to mention it.
But if you for example use, Gentoo, Fedora or an older version of debian/ubuntu or maybe debian unstable, you can run into this issue. Maybe I'll can put the explanation from the comments up to the answer and add that this won't be a solution if you have the latest official binaries.
Fedora or an older version of debian/ubuntu or maybe debian unstable, you can run into this issue
only if you deliberately try to install binary packages that are from another distribution I would say.
Could you give an example of how this could happen if you install the binary packages from the ROS buildfarm that target the same OS (ie: buildfarm provides pkgs for 18.04, user has 18.04)? ABI compatibility is guaranteed for Debian/Ubuntu. They can change glibc, but only in an ABI bw-compatible manner.
Even if roscpp hasn't been rebuilt with a newer glibc version in that case, it should still work, as breaking ABI during the lifetime of a Debian distribution is not allowed afaik.
Asked: 2020-01-18 16:04:06 -0500
Seen: 378 times
Last updated: Jan 24 '20
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
