ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

Catkin finding wrong version of Boost

I recently tried switching a workspace to build an install space and it fails due to a Boost configuration issue (threading disabled). On further inspection, I saw that CMake was actually building against a different Boost installation in /opt provided by some 3rd party software I have installed. When I set BOOST_ROOT to /usr as a catkin build argument everything worked fine.

Anyone know why this happened? I would very much prefer not to have to explicitly tell catkin/cmake to use the system Boost installation over some random files found in /opt.

[Edit: this does happen when building only devel space]

edit retag close merge delete

different Boost installation in /opt provided by some 3rd party software

Does the "3rd party software" also set any environment variables? /opt is typically not on the CMake search path for these kind of things, so it would seem strange that it's looking there.

As to install vs devel: ..

( 2018-10-10 13:37:04 -0600 )edit

.. this might a quirk: have you observed the same behaviour after a catkin clean -y of the same workspace first?

( 2018-10-10 13:37:46 -0600 )edit

So yeah, I apparently hadn't tried a full clean build of just the devel space. The same issue appeared there. The software in question is the Universal Robots urtool package. I can see it sets URTOOL_ROOT and URTOOL_TARGET environment variables but that doesn't seem like a problem.

( 2018-10-10 16:53:49 -0600 )edit

So this is most likely not a Catkin problem as the title suggests, but a CMake one.

If you write a very minimal non-ROS CMakeLists.txt with just a find_package(Boost ..) etc in there (so add the minimal required statements), does that also exhibit the problem?

( 2018-10-11 04:02:11 -0600 )edit

Sorry to lose track of this last week. You're correct, it's just CMake that is getting misled. See the answer I've added for my latest update.

( 2018-10-17 09:13:44 -0600 )edit

Sort by » oldest newest most voted

I at least found what was causing CMake to go to the wrong version, though I still don't understand why. The 3rd party software is the Universal Robots SDK and during install it had added /opt/urtool-3.0/bin to my PATH. Removing it from PATH allows CMake to find the correct Boost installation.

If anyone knows how the PATH variable can affect CMake, I'd be interested to know as I couldn't find any reference to it in CMake documentation. I've listed the contents of the urtool-3.0/bin folder below and I don't see how any of them could affect it either.

[I] ~> ls -la /opt/urtool-3.0/bin/
total 14400
drwxr-xr-x  2 root root    4096 Sep  8 22:14 ./
drwxr-xr-x 13 root root    4096 Sep  8 22:14 ../
-rwxr-xr-x  1 root root  198404 Jun  6  2016 curl*
-rwxr-xr-x  1 root root    5073 Jun  6  2016 curl-config*
-rwxr-xr-x  1 root root  573920 Jun  6  2016 i686-unknown-linux-gnu-addr2line*
-rwxr-xr-x  1 root root  540928 Jun  6  2016 i686-unknown-linux-gnu-ar*
-rwxr-xr-x  1 root root  780256 Jun  6  2016 i686-unknown-linux-gnu-as*
-rwxr-xr-x  2 root root  132032 Jun  6  2016 i686-unknown-linux-gnu-c++*
-rwxr-xr-x  1 root root  570080 Jun  6  2016 i686-unknown-linux-gnu-c++filt*
-rwxr-xr-x  1 root root  130688 Jun  6  2016 i686-unknown-linux-gnu-cpp*
-rwxr-xr-x  2 root root  132032 Jun  6  2016 i686-unknown-linux-gnu-g++*
-rwxr-xr-x  2 root root  129504 Jun  6  2016 i686-unknown-linux-gnu-gcc*
-rwxr-xr-x  2 root root  129504 Jun  6  2016 i686-unknown-linux-gnu-gcc-4.1.2*
-rwxr-xr-x  1 root root   16233 Jun  6  2016 i686-unknown-linux-gnu-gccbug*
-rwxr-xr-x  1 root root   27360 Jun  6  2016 i686-unknown-linux-gnu-gcov*
-rwxr-xr-x  1 root root 2809256 Jun  6  2016 i686-unknown-linux-gnu-gdb*
-rwxr-xr-x  1 root root 2809256 Jun  6  2016 i686-unknown-linux-gnu-gdbtui*
-rwxr-xr-x  1 root root  849272 Jun  6  2016 i686-unknown-linux-gnu-ld*
-rwxr-xr-x  1 root root  583552 Jun  6  2016 i686-unknown-linux-gnu-nm*
-rwxr-xr-x  1 root root  737536 Jun  6  2016 i686-unknown-linux-gnu-objcopy*
-rwxr-xr-x  1 root root  822656 Jun  6  2016 i686-unknown-linux-gnu-objdump*
-rwxr-xr-x  1 root root  540928 Jun  6  2016 i686-unknown-linux-gnu-ranlib*
-rwxr-xr-x  1 root root  225280 Jun  6  2016 i686-unknown-linux-gnu-readelf*
-rwxr-xr-x  1 root root  516536 Jun  6  2016 i686-unknown-linux-gnu-size*
-rwxr-xr-x  1 root root  516568 Jun  6  2016 i686-unknown-linux-gnu-strings*
-rwxr-xr-x  1 root root  737536 Jun  6  2016 i686-unknown-linux-gnu-strip*
-rw-r--r--  1 root root    1577 Jun  6  2016 ptxconfig
-rwxr-xr-x  1 root root    5889 Jun  6  2016 scons*
-rwxr-xr-x  1 root root    5889 Jun  6  2016 scons-1.2.0*
-rwxr-xr-x  1 root root   16572 Jun  6  2016 sconsign*
-rwxr-xr-x  1 root root   16572 Jun  6  2016 sconsign-1.2.0*
-rwxr-xr-x  1 root root   48685 Jun  6  2016 scons-time*
-rwxr-xr-x  1 root root   48685 Jun  6  2016 scons-time-1.2.0*
-rwxr-xr-x  1 root root    6871 Jun  6  2016 xmlrpc-c-config*

more

I believe PATH is one of the variables that is used to setup the FindBoost.cmake search path. On Windows, only DLLs that are on the PATH are actually considered by the loader fi.

Most likely that is why CMake is considering those directories as well.

( 2018-10-17 15:56:31 -0600 )edit

The directory you show btw is essentially a cross-compiler for UR controllers.

( 2018-10-17 15:57:06 -0600 )edit

Thanks for your help. I guess I'll just have to be more careful in the future of what gets on the system path.

( 2018-10-17 16:23:19 -0600 )edit

CMake doesn't normally look for boost in /opt, so I suspect the third-party software that you've installed has set the CMAKE_PREFIX_PATH or BOOST_ROOT environment variables to point to its version of boost.

CMake only searches for dependencies during configuration time when the build mode, build flags or CMakeLists files change, so it may be that you're only seeing this now because you're changing the build flags, and haven't made other CMakeLists changes in while. I suspect if you clean your workspace and try another devel build, you'll see the same boost issues.

more

Turned out to be the PATH variable. Any idea how that affects CMake?

( 2018-10-17 09:23:11 -0600 )edit