ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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 SEGFAULT
s 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
.
2 | No.2 Revision |
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 SEGFAULT
s 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
.
3 | No.3 Revision |
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 SEGFAULT
s 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
.
4 | No.4 Revision |
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 SEGFAULT
s 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 bycmake/make/make install
and installed in/usr/local/lib
. This doesn't appear to be an issue in this particular case, actually, butcatkin
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
.