Revision history [back]

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.

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 ..)). 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.

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.involved (just search around, the internet is full of examples).

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 ..)). 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.

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).

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.

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).

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.