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]
Asked by jdlangs on 2018-10-10 09:30:15 UTC
Answers
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.
Asked by ahendrix on 2018-10-10 13:37:36 UTC
Comments
Turned out to be the PATH variable. Any idea how that affects CMake?
Asked by jdlangs on 2018-10-17 09:23:11 UTC
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*
Asked by jdlangs on 2018-10-17 09:11:48 UTC
Comments
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.
Asked by gvdhoorn on 2018-10-17 15:56:31 UTC
The directory you show btw is essentially a cross-compiler for UR controllers.
Asked by gvdhoorn on 2018-10-17 15:57:06 UTC
Thanks for your help. I guess I'll just have to be more careful in the future of what gets on the system path.
Asked by jdlangs on 2018-10-17 16:23:19 UTC
Comments
Does the "3rd party software" also set any environment variables?
/optis typically not on the CMake search path for these kind of things, so it would seem strange that it's looking there.As to
installvsdevel: ..Asked by gvdhoorn on 2018-10-10 13:37:04 UTC
.. this might a quirk: have you observed the same behaviour after a
catkin clean -yof the same workspace first?Asked by gvdhoorn on 2018-10-10 13:37:46 UTC
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_ROOTandURTOOL_TARGETenvironment variables but that doesn't seem like a problem.Asked by jdlangs on 2018-10-10 16:53:49 UTC
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.txtwith just afind_package(Boost ..)etc in there (so add the minimal required statements), does that also exhibit the problem?Asked by gvdhoorn on 2018-10-11 04:02:11 UTC
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.
Asked by jdlangs on 2018-10-17 09:13:44 UTC