View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007783CMakeCMakepublic2008-10-07 02:212008-10-23 09:41
Reporteredice 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007783: FindBoost (2.6.2) does not find correct version even if BOOST_ROOT is set
DescriptionI'm using CMake 2.6.2 (I checked, it is using the latest FindBoost.cmake 1.4.2.7)

I wanted to reopen bug 7456 but it appears the "Reopen" or "Feedback" buttons are unavailable?

Regardless, I have boost 1.33.1 installed at
/home/paul/usr/lnx/include/boost-1_33_1
/home/paul/usr/lnx/lib

I have boost 1.36.0 installed at
/home/paul/usr/lnx/share/boost-1_36_0/include
/home/paul/usr/lnx/share/boost-1_36_0/lib

I set BOOST_ROOT to /home/paul/usr/lnx/share/boost-1_36_0
I set the required version to 1.36.0

However, it will always find and check 1.33.1's version.hpp, and never seems to even check the 1.36.0 files.


I tried analysing the inputs and outputs of line 313
    FIND_PATH(Boost_INCLUDE_DIR
      NAMES boost/config.hpp
      HINTS ${_boost_INCLUDE_SEARCH_DIRS}
      PATH_SUFFIXES ${_boost_PATH_SUFFIXES}
      )

_boost_INCLUDE_SEARCH_DIRS =
 /home/paul/usr/lnx/share/boost-1_36_0/include;/home/paul/usr/lnx/share/boost-1_36_0;C:/boost/include;C:/boost;/boost/boost_1_36_0;/Boost;/sw/local/include

_boost_PATH_SUFFIXES =
boost-1_36_1;boost-1_36_0;boost-1_36;boost-1_35_1;boost-1_35_0;boost-1_35;boost-1_34_1;boost-1_34_0;boost-1_34;boost-1_33_1;boost-1_33_0;boost-1_33


I am not sure why it does not find 1.36.0's version.hpp first since its path is the first in the list (does not mean highest priority?)


But I am more concerned with WHY is cmake looking for boost in places OTHER than BOOST_ROOT... and why is it looking for versions OTHER than the one I have specified.


What happens if I have 2 x boost 1.36.0 installed? This is very possible - the stock version and a version with something tweaked eg -DBOOST_SIGNALS_NAMESPACE=signalslib (for compatibility with Qt3)


Instead, I am set()ing all of the include paths and library paths manually, to ensure I get the right library.

TagsNo tags attached.
Attached Filestxt file icon boost_strace_output.txt [^] (17,057 bytes) 2008-10-10 02:56 [Show Content]
txt file icon CMakeLists.txt [^] (381 bytes) 2008-10-10 04:00 [Show Content]

 Relationships
related to 0007456closedDouglas Gregor FindBoost (2.6.1) does not find correct version if BOOST_ROOT is set and another version is installed in /usr 
related to 0008112closedBrad King Regression of CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH with regard to PATH_SUFFIXES 

  Notes
(0013740)
edice (reporter)
2008-10-07 02:45

Note that the title should say 2.6.2 NOT 2.6.1. How do you edit bug titles in Mantis?
(0013823)
Brad King (manager)
2008-10-09 16:10

I fixed the bug title for you. I think only developers can do it.
(0013824)
Brad King (manager)
2008-10-09 16:22

What was the exact find_package call you used?

  find_package(Boost 1.36.0 EXACT)

will look for only 1.36.0. However,

  find_package(Boost 1.36.0)

will look for version 1.36.0 *or higher*.

Currently there is a bug that will cause the latter case to find one that is lower if a higher or equal version cannot be found. However, even then it will complain that the found version is too old.

I don't know why it is finding 1.33 when version 1.36 is listed first in the search path. I cannot reproduce that problem. Please try running cmake with 'strace' and grep in the output for 'include/boost' to see exactly where it is looking.
(0013825)
Brad King (manager)
2008-10-09 17:05

I've fixed the problem of considering paths for versions less than requested:

/cvsroot/CMake/CMake/Modules/FindBoost.cmake,v <-- Modules/FindBoost.cmake
new revision: 1.15; previous revision: 1.14

I'd still like to know the results from strace, though. That is a separate problem.
(0013830)
edice (reporter)
2008-10-10 03:59

Useful tool, strace...

Looks like it is assuming BOOST_ROOT will have root/include/boost-1_36_0/config.hpp

I had compiled it to 'stage' and then pointed boost root at that, so I wanted it to find
root/boost/config.hpp
or
root/include/boost/config.hpp
where include is a dir with a link to boost inside.

I want to keep the boost files all in one (boost) root directory so that the libraries don't all live together in one tremendous /mydev/lib directory. Yes the include files go into /include/boost-etc but all the libs go into /lib

See also attached, the CMakeLists.txt file I used to generate the strace.
(0013859)
Brad King (manager)
2008-10-13 09:51

Thanks for the strace output. I've found the problem. In fact it doesn't expect root/include/boost-1_36_0/boost/config.hpp and will *eventually* try root/boost/config.hpp but not until after it has tried all the other versions. Of course before it gets there it hits the older version.

This is actually a bug in FIND_PATH (and FIND_LIBRARY, etc.), not in the FindBoost.cmake module. The problem is that they are trying the entire search path with the PATH_SUFFIXES provided and then the entire search path with no suffixes. The correct behavior would be to try each entry in the entire search path each with the PATH_SUFFIXES and then directly before moving on to the next entry.
(0013860)
Brad King (manager)
2008-10-13 09:59

I've fixed the FIND_PATH problem:

/cvsroot/CMake/CMake/Source/cmFindBase.cxx,v <-- Source/cmFindBase.cxx
new revision: 1.50; previous revision: 1.49

Please try the next 2.6.3 release candidate when it is announced.
(0013871)
edice (reporter)
2008-10-13 20:25

Can I please double-check the fix?

I think I now understand (more of) the problem. But I'm not sure that the fix is correct.

If FindBoost wants to also search in the paths without a suffix, shouldn't it also specify a '/' blank suffix?


The documentation for find_file, strangely documents find_path

http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_file [^]

and it states:
PATH_SUFFIXES can be used to give sub directories that will be appended to the search paths.


So if I were writing a cmake module, I would expect that if I gave find_path some suffixes, it would *only* look in those suffix paths, not in any paths without one of the suffixes.


what do you think?
(0013877)
Brad King (manager)
2008-10-14 08:43

Certainly you can check the fix, and then re-open the report if it doesn't work. I always close bugs right after fixing them because many reporters don't bother responding once it is fixed and then the bug sits open for months before I notice.

We cannot change the behavior of find_path because existing calls have already been written that expect it to look with and without the suffixes added. Also, when a user sets CMAKE_INCLUDE_PATH or some other variable in his/her environment to point at exactly the location of the header to be found, the command had better find it.

I've updated the PATH_SUFFIXES documentation:

/cvsroot/CMake/CMake/Source/cmFindBase.cxx,v <-- Source/cmFindBase.cxx
new revision: 1.51; previous revision: 1.50

 Issue History
Date Modified Username Field Change
2008-10-07 02:21 edice New Issue
2008-10-07 02:45 edice Note Added: 0013740
2008-10-07 10:12 Bill Hoffman Status new => assigned
2008-10-07 10:12 Bill Hoffman Assigned To => Douglas Gregor
2008-10-07 10:58 Brad King Relationship added related to 0007456
2008-10-09 16:00 Brad King Summary (reopening 0007456): FindBoost (2.6.1) does not find correct version even if BOOST_ROOT is set => FindBoost (2.6.2) does not find correct version even if BOOST_ROOT is set
2008-10-09 16:00 Brad King Description Updated
2008-10-09 16:10 Brad King Note Added: 0013823
2008-10-09 16:22 Brad King Note Added: 0013824
2008-10-09 17:05 Brad King Note Added: 0013825
2008-10-09 17:05 Brad King Assigned To Douglas Gregor => Brad King
2008-10-10 02:56 edice File Added: boost_strace_output.txt
2008-10-10 03:59 edice Note Added: 0013830
2008-10-10 04:00 edice File Added: CMakeLists.txt
2008-10-13 09:51 Brad King Note Added: 0013859
2008-10-13 09:59 Brad King Status assigned => closed
2008-10-13 09:59 Brad King Note Added: 0013860
2008-10-13 09:59 Brad King Resolution open => fixed
2008-10-13 20:25 edice Status closed => feedback
2008-10-13 20:25 edice Resolution fixed => reopened
2008-10-13 20:25 edice Note Added: 0013871
2008-10-14 08:43 Brad King Note Added: 0013877
2008-10-23 09:41 Brad King Status feedback => closed
2008-10-23 09:41 Brad King Resolution reopened => fixed
2008-11-18 09:56 Brad King Relationship added related to 0008112


Copyright © 2000 - 2018 MantisBT Team