ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
4

ROS dependency Boost 1.58, additional dependency Boost 1.64?

asked 2017-10-25 03:27:36 -0500

Hendrik Wiese gravatar image

updated 2017-10-25 03:30:04 -0500

Hey everyone,

I've got a problem here that I seem unable to solve... or even fully get my head around.

ROS itself installs libboost 1.58 as one of its dependencies. In addition I have a 3rd party dependency for a node of libboost 1.64. Boost 1.58 is installed via apt in /usr/lib/x86_64-linux-gnu as usual and comes with ros-kinetic-desktop-full. So deinstalling it isn't an option.

Boost 1.64 on the other hand is manually built by cmake/make/make install and installed in /usr/local/lib. This doesn't appear to be an issue in this particular case, actually, but catkin warns about not being able to generate a safe linker path. The node actually works. The warning is annoying though, and I'd like to somehow cleanly solve this issue instead of just suppressing the warning. But if there's no other way, I'd go with simply deactivating that particular warning.

How should I deal with this?

Thanks

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
6

answered 2017-10-25 03:41:41 -0500

gvdhoorn gravatar image

updated 2017-10-25 04:17:55 -0500

How should I deal with this?

Ideally: avoid trying to use two different Boost versions on the same machine. Or at least: make sure that they are only visible (ie: findable) by the applications that need them.

Mixing Boost versions like this can lead to subtle and hard to diagnose SEGFAULTs and other problems. Even in the case where one Boost library is header only, and linking is not even involved (just search around, the internet is full of examples).

Boost 1.64 on the other hand is manually built by cmake/make/make install and installed in /usr/local/lib. This doesn't appear to be an issue in this particular case, actually, but catkin warns about not being able to generate a safe linker path. The node actually works. The warning is annoying though, and I'd like to somehow cleanly solve this issue instead of just suppressing the warning. But if there's no other way, I'd go with simply deactivating that particular warning.

One suggestion: if you're compling the node that needs the newer Boost version yourself (and I assume that is the case, as ROS Kinetic binaries are built against 1.58), a somewhat clean work-around could be to move the 1.64 artefacts to a location that is not on the default include, linker and search paths. Use the regular CMake knobs to tell the CMakeLists.txt that need it (ie: the node that needs 1.64) where to find it and to require it (something like find_package(Boost REQUIRED 1.64 EXACT ..)). It could be that running binaries built this way need some tweaking of library search paths afterwards, but that is all non-ROS specific (all of this is, actually).

If done correctly, this should avoid inadvertent mixing of libraries and headers of the two Boost versions.

Note that you'll probably have to clean out the 1.64 install you have in /usr/local already, and rebuild it with a suitable PREFIX.

edit flag offensive delete link more

Comments

It's not absolutely necessary to get the non-default Boost off the default search paths, but it's probably the easiest way to avoid running into any issues later. /usr/local is (I believe) searched first, so every find_package(Boost ..) is going to find it, and again: mixing is not a good idea.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-25 03:44:42 -0500 )edit

I'll see if I can make the node link against (maybe even statically) some "locally" installed boost 1.64 while removing the latter from /usr/local and keeping only 1.58 in the system search paths. Prbbly gonna be a hell of a ride. I also hope to get rid of some weird node shutdown behavior by this.

Hendrik Wiese gravatar image Hendrik Wiese  ( 2017-10-25 04:53:59 -0500 )edit

It shouldn't be too difficult: dealing with multiple versions of libraries is something that CMake can do since a long time.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-25 05:02:05 -0500 )edit

Keep in mind though that 'the rest' of ROS Kinetic (ie: all libraries that you use) will still bring in Boost 1.58 artefacts. That is not going to change, and can still lead to issues.

The only way to really avoid that is to build ROS (all of it) from sources against 1.64.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-25 05:03:17 -0500 )edit

And finally: this problem - linking against different versions of dependencies in a single compilation unit - is not ROS specific. It's a universal problem when dealing with languages that support (dynamic) linking (ie: even Python has it).

It's called the dependency hell.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-25 05:09:20 -0500 )edit

For anyone having problems with multiple version dependency when working in ROS, this link may useful. The example demonstrates very much @gvdhoom 's explanation

DangTran gravatar image DangTran  ( 2020-05-22 22:06:35 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2017-10-25 03:27:36 -0500

Seen: 5,064 times

Last updated: Oct 25 '17