Notes
(0029434) Pat Marion (reporter) 2012-05-09 12:32	This bug still exists. The solution is explained here: http://www.cmake.org/pipermail/cmake/2010-May/037163.html [^] The issue is that FindBoost.cmake searches first for libraries with the -mt (multithreaded) suffix and finds them in /usr/lib but not in the local install dir because the local install has mt disabled.

(0030417) David Cole (manager) 2012-08-11 21:35	Sending old, never assigned issues to the backlog. (The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...) If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.

(0030705) Philip Lowman (developer) 2012-08-18 18:24	In addition to the suggestion Pat made on 5/9 you could also set Boost_NO_SYSTEM_PATHS which will exclude /usr/lib from your searches. I'm open to suggestions or patches on how we could improve the code to try to detect this problem. It stems from needing the code to search for (e.g.) libboost_system.so / libboost_system.a. Distributions like Ubuntu don't include the full boost version number with the static libraries. /usr/lib/libboost_system.a /usr/lib/libboost_system-mt.a /usr/lib/libboost_system-mt.so /usr/lib/libboost_system.so /usr/lib/libboost_system.so.1.46.1 As a result, we can't safely delete the last line in the list of these checks. # # Find RELEASE libraries # set(_boost_RELEASE_NAMES ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION} ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG} ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION} ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG} ${Boost_LIB_PREFIX}boost_${COMPONENT} ) Seems like the only thing we could do is detect that Boost libraries are being sourced from multiple prefixes (somehow) and either prevent it from happening (by dynamically manipulating the search paths after the first library is found) or warning/erroring about it afterwards. I'm open to patches if someone has time to work on this issue, but I think the workarounds are sufficient for now.

(0041826) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2011-03-30 17:05	Clinton Stimpson	New Issue
2012-05-09 12:32	Pat Marion	Note Added: 0029434
2012-08-11 21:35	David Cole	Status	new => backlog
2012-08-11 21:35	David Cole	Note Added: 0030417
2012-08-18 15:29	Philip Lowman	Status	backlog => assigned
2012-08-18 15:29	Philip Lowman	Assigned To	=> Philip Lowman
2012-08-18 18:24	Philip Lowman	Note Added: 0030705
2012-08-18 18:27	Philip Lowman	Status	assigned => backlog
2016-06-10 14:28	Kitware Robot	Note Added: 0041826
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships