MantisBT - CMake
View Issue Details
0007456CMakeCMakepublic2008-08-06 03:232008-09-23 08:14
Martin Apel 
Douglas Gregor 
normalmajoralways
closedfixed 
CMake-2-6 
 
0007456: FindBoost (2.6.1) does not find correct version if BOOST_ROOT is set and another version is installed in /usr
Setup is as follows:
OS is Linux.
Boost version 1.32 is installed globally, i.e. under /usr/include and /usr/lib
A local version 1.35 is installed in some other path, BOOST_ROOT is set accordingly.
When searching for the version with the following call
  Find_Package(Boost 1.34.1 COMPONENTS filesystem signals program_options REQUIRED)
FindBoost finds the version in /usr/include and complains, that this version is too old. The correct version is not found, although BOOST_ROOT is set correctly.
This is a regression from 2.6.0. Unfortunately I didn't find this with any of the release candidates, because I did not try it on all machines. Only some of my machines have two Boost versions installed.
No tags attached.
related to 0007783closed Brad King FindBoost (2.6.2) does not find correct version even if BOOST_ROOT is set 
Issue History
2008-08-06 03:23Martin ApelNew Issue
2008-08-14 20:00reedacartwrightNote Added: 0013031
2008-08-19 13:53Bill HoffmanStatusnew => assigned
2008-08-19 13:53Bill HoffmanAssigned To => Douglas Gregor
2008-08-22 14:27Philip LowmanNote Added: 0013156
2008-09-15 09:46Bill HoffmanNote Added: 0013466
2008-09-15 10:46Martin ApelNote Added: 0013471
2008-09-15 15:15Brad KingNote Added: 0013475
2008-09-16 10:31Brad KingNote Added: 0013479
2008-09-23 00:52Douglas GregorNote Added: 0013553
2008-09-23 03:13Martin ApelNote Added: 0013554
2008-09-23 08:14Brad KingStatusassigned => closed
2008-09-23 08:14Brad KingResolutionopen => fixed
2008-10-07 10:58Brad KingRelationship addedrelated to 0007783

Notes
(0013031)
reedacartwright   
2008-08-14 20:00   
I've encountered this as well.

The issue occurs in the loop beginning on line 289 in FindBoost.cmake. This loop enumerates over possible version numbers and does a FIND_PATH for each one. Because neither NO_DEFAULT_PATH nor NO_CMAKE_SYSTEM_PATH is specified for the FIND_PATH command, /usr/include (etc.) will also be checked for boost/config.hpp. If boost is installed there, FIND_PATH will be successful and it will stop after one iteration of the loop.

The solution is to only check the default paths after the suffixed paths have been tried. This could be done by moving the FIND_PATH after the loop and pass all known suffixes to it, with the loop storing the suffixes into an array.

A workaround is to symlink BOOST_ROOT/include/boost_1_35/boost to BOOST_ROOT/include/boost.
(0013156)
Philip Lowman   
2008-08-22 14:27   
I also got impacted by this bug today. Will a fix be forthcoming in 2.6.2?
(0013466)
Bill Hoffman   
2008-09-15 09:46   
The new HINTS option should work for this, no need for NO_SYSTEM stuff anymore. It must be that BOOST_ROOT is not being used...

Could one of you add a message that prints out ${_boost_INCLUDE_SEARCH_DIRS} before the find around 289?
(0013471)
Martin Apel   
2008-09-15 10:46   
I added a print, although the find is on line 308 in version 2.6.2 RC 3, which I used. The output is as follows:

_boost_INCLUDE_SEARCH_DIRS is /scratch/apel/boost_install/linux32/include;/scratch/apel/boost_install/linux32;C:/boost/include;C:/boost;/boost/boost_1_34_1;/Boost;/sw/local/include

where /scratch/apel/boost_install/linux32 is what I set BOOST_ROOT to.

Hope this helps.
(0013475)
Brad King   
2008-09-15 15:15   
The HINTS option does not help when there are multiple calls and it is not the first one that finds the header. Here is a patch doing what the reporter suggests. It does fix the problem. Okay to commit, Doug?

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 448707c..dddea98 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -286,8 +286,9 @@ ELSE (_boost_IN_CACHE)
 
   # Try to find Boost by stepping backwards through the Boost versions
   # we know about.
- FOREACH(_boost_VER ${_boost_TEST_VERSIONS})
- IF( NOT Boost_INCLUDE_DIR )
+ IF( NOT Boost_INCLUDE_DIR )
+ SET(_boost_PATH_SUFFIXES)
+ FOREACH(_boost_VER ${_boost_TEST_VERSIONS})
       # Add in a path suffix, based on the required version, ideally
       # we could read this from version.hpp, but for that to work we'd
       # need to know the include dir already
@@ -304,15 +305,16 @@ ELSE (_boost_IN_CACHE)
           STRING(REGEX REPLACE "([0-9]+)\\.([0-9]+)" "\\1_\\2"
             _boost_PATH_SUFFIX ${_boost_PATH_SUFFIX})
       ENDIF(_boost_PATH_SUFFIX MATCHES "[0-9]+\\.[0-9]+\\.[0-9]+")
+ LIST(APPEND _boost_PATH_SUFFIXES "${_boost_PATH_SUFFIX}")
+ ENDFOREACH(_boost_VER)
 
- FIND_PATH(Boost_INCLUDE_DIR
- NAMES boost/config.hpp
- HINTS ${_boost_INCLUDE_SEARCH_DIRS}
- PATH_SUFFIXES ${_boost_PATH_SUFFIX}
+ FIND_PATH(Boost_INCLUDE_DIR
+ NAMES boost/config.hpp
+ HINTS ${_boost_INCLUDE_SEARCH_DIRS}
+ PATH_SUFFIXES ${_boost_PATH_SUFFIXES}
       )
 
- ENDIF( NOT Boost_INCLUDE_DIR )
- ENDFOREACH(_boost_VER)
+ ENDIF( NOT Boost_INCLUDE_DIR )
 
   IF(Boost_INCLUDE_DIR)
     # Extract Boost_VERSION and Boost_LIB_VERSION from version.hpp
(0013479)
Brad King   
2008-09-16 10:31   
Okay, I've committed the above patch with a few more comments.

/cvsroot/CMake/CMake/Modules/FindBoost.cmake,v <-- Modules/FindBoost.cmake
new revision: 1.14; previous revision: 1.13
(0013553)
Douglas Gregor   
2008-09-23 00:52   
This patch looks reasonable. Longer term, I'd like FindBoost to do more checking of the found boost/config.hpp (e.g., to see if it's an acceptable version) within a loop like this.
(0013554)
Martin Apel   
2008-09-23 03:13   
I tested 2.6.2-RC5 on 3 Linux machines; on two of these the described problem showed up with older versions. With RC5 all machines find the correct Boost version.