[CMake] FIND_LIBRARY in FindBoost finds wrong library

[Chuck Atkins]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100319/6c7f60a0/attachment-0001.htm>