[CMake] FIND_LIBRARY in FindBoost finds wrong library

[Marcel Loose]

Hi Chuck,

Whatever way you look at it, problems will likely arise sooner or later
with different Boost versions. I ran into this problem
because /usr/lib/libboost_date_time-mt.so was found
before /home/loose/boost-1.40.0/lib/libboost_date_time.so.

My point in turning the loop inside out stems from the fact that there
are dozens of FindXXX modules that may be vulnerable to the same
problem. To name a few: FindGTK, FindLua50, FindPNG, FindWxWindows, etc.

W.r.t. FindBoost, maybe it's wise to use BOOST_ROOT exclusively when
specified. That would at least preclude the current problems.

BTW: Is there a reason why I cannot specify options like
NO_CMAKE_ENVIRONMENT_PATH, NO_SYSTEM_ENVIRONMENT_PATH, etc. with
FIND_PACKAGE(), except when using config mode?

Best regards,
Marcel Loose.

On Fri, 2010-03-19 at 10:22 -0400, Chuck Atkins wrote:
> With multiple versions installed, setting the BOOST_ROOT variable will
> force the FindBoost module to search the desired location first.
> Turning the loop inside out wouldn't really solve the problem when
> multiple libraries are searched for (date_time, thread).  The problem
> arises when multiple versions are available with different
> capabilities.  For example:  boost installed in /usr/local has all the
> libraries available but the one installed
> in /home/myuser/projects/boost-1.41.0 might only have a partial subset
> of the libraries available, say only date_time and thread for example.
> Since the FindBoost module searches the BOOST_ROOT path in addition to
> the other paths,  a conflict could arise where the module finds
> something like:
> 
> /home/myuser/projects/boost-1.41.0/lib/libboost_date_time-mt.so
> /home/myuser/projects/boost-1.41.0/lib/libboost_thread-mt.so
> /usr/local/lib/libboost_filesystem-mt.so
> /usr/local/lib/libboost_python-mt.so
> 
> This mix and match is definitely not desired.  It almost seems like if
> the BOOST_ROOT variable is set then that should get used exclusively
> as the search path and not just appended to the front.
> 
> Thoughts?
> 
> Chuck Atkins
> 
> 
> On Fri, Mar 19, 2010 at 7:12 AM, Marcel Loose <loose at astron.nl> wrote:
>         Hi Michael,
>         
>         That still doesn't answer my question about turning that loop
>         inside
>         out.
>         
>         A quick grep in the CMake Modules directory showed me that
>         there are at
>         least a dozen other FindXXX scripts that use multiple NAMES
>         with a
>         FIND_XXX() commands. I haven't checked how they handle default
>         (system)
>         paths, but I guess these might be erratic as well, when
>         multiple
>         versions of a package exists with libraries named slightly
>         different.
>         
>         Best regards,
>         Marcel Loose.
>         
>         
>         On Fri, 2010-03-19 at 06:50 -0400, Philip Lowman wrote:
>         > Someone could add an option to FindBoost that will simply
>         exclude the
>         > system paths from the search.  This has never been implied
>         by setting
>         > BOOST_ROOT.  As long as the unversioned library names are
>         being
>         > searched for with find_library they are likely going to be
>         found.
>         > Currently the onus is on the user to double check what
>         FindBoost
>         > discovers.
>         >
>         > > On Mar 19, 2010 4:56 AM, "Marcel Loose" <loose at astron.nl>
>         wrote:
>         > >
>         > > Well, in my case, the library name was not even that
>         specific.
>         > > It found /usr/lib/libboost_date_time-mt.so
>         > >
>         before
/home/loose/boost/boost-1.40.0/lib/libboost_date_time.so,
>         > > simply
>         > > because libboost_date_time-mt.so is searched for in *all*
>         paths
>         > > before
>         > > libboost_date_time.so.
>         > >
>         > > Anyway, I still think this is (also) a CMake issue. IMHO
>         it would
>         > > make
>         > > sense to turn the loop in
>         cmFindLibraryCommand::FindNormalLibrary()
>         > > inside out. What's your opinion?
>         > >
>         > > Best regards,
>         > > Marcel Loose.
>         > >
>         > >
>         > > On Thu, 2010-03-18 at 10:05 -0400, Michael Jackson wrote:
>         > I
>         > > thought there was now an option the b...
>         > >
>         >
>         
>         
>         
>         
>         _______________________________________________
>         Powered by www.kitware.com
>         
>         Visit other Kitware open-source projects at
>         http://www.kitware.com/opensource/opensource.html
>         
>         Please keep messages on-topic and check the CMake FAQ at:
>         http://www.cmake.org/Wiki/CMake_FAQ
>         
>         Follow this link to subscribe/unsubscribe:
>         http://www.cmake.org/mailman/listinfo/cmake
>         
>