Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
On Mon, Mar 22, 2010 at 4:05 AM, Marcel Loose wrote: > 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? You could modify the FIND_PACKAGE() interface to support options like these and then fix all of the CMake modules to handle the new options. Alternatively, there could be a global CMake property or variable for enabling these. A combination could also be used (if necessary, property is set at start of find_package() and subsequently unset at end). -- Philip Lowman ___ 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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
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 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" > 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 > > ___ Powered by www.kitware.com Visit other Kitware open-source projects at
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
On Fri, Mar 19, 2010 at 10:22 AM, Chuck Atkins wrote: > /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. I've had the same thought (and wish it had been implemented that way) but refrained from changing the behavior of this in the past, mainly because it could break some people's builds (some people may treat BOOST_ROOT as a "use it if it's there" feature or have it accidentally set while building on certain platforms where Boost is provided in the system path). Also, FindBoost would need to check the environment variables BOOST_ROOT and possibly BOOST_LIBRARYDIR and BOOST_INCLUDEDIR as well and if they are set enable this new behavior. > Thoughts? I could add a public variable to FindBoost which disables searching the system paths and call it out in the documentation. It would basically set NO_CMAKE_SYSTEM_PATH on all of the find_library() and find_path() calls. Alternatively, we could make the module behave as you describe and hope that it doesn't break too many people. What do you think? -- Philip Lowman ___ 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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
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 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" 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 > ___ 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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
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" 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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
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" 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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
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 boost build system to NOT add
> all the "very specific" naming of each library which is now the
> default. There is a way to turn that back on. You will have to search
> through the boost-build docs for that info.
>
> ___
> Mike Jackson www.bluequartz.net
> Principal Software Engineer mike.jack...@bluequartz.net
> BlueQuartz Software Dayton, Ohio
>
>
> On Mar 18, 2010, at 9:47 AM, Marcel Loose wrote:
>
> > Hi all,
> >
> > I ran into a problem with FindBoost where it fails to find the
correct
> > version of a component library. The cause is pretty clear to me.
> >
> > There's a system-wide (rather old) version of Boost installed and
> > there's my latest-greatest version of Boost. The FindBoost macro
> > searches for a library using rather specific names first and generic
> > names last. These are all listed under NAMES. FIND_LIBRARY() tries
to
> > find each name in all paths specified under PATHS.
> >
> > Problem is that (for reasons I do not really know) the very specific
> > library name is not present in my latest-greatest directory, but it
IS
> > present in /usr/lib.
> >
> > This problem is closely related to a post on this list a couple of
> > months ago:
http://www.mail-archive.com/cmake@cmake.org/msg24565.html
> > Unfortunately, no-one ever replied to that post.
> >
> > Basically, the author of that post suggested to turn the loop in
> > cmFindLibraryCommand::FindNormalLibrary() inside out: i.e.
> > for(path in paths)
> > {
> > for(name in names)
> > {
> >find name in path;
> >if found return name;
> > }
> > }
> >
> > Any thoughts on this?
> >
> > Best regards,
> > Marcel Loose.
> >
> > ___
> > 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
>
___
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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
On Mar 18, 2010, at 7:47 AM, Marcel Loose wrote: > I ran into a problem with FindBoost where it fails to find the correct > version of a component library. The cause is pretty clear to me. This isn't an answer to your question, but have you tried the CMake version of boost? I have found it much easier to build and it plays well with other CMake build systems... http://sodium.resophonic.com/boost-cmake/current-docs/ The only drawback is that it isn't updated as frequently as the bjam boost distribution (1.42 still hasn't been released on the CMake build system). James ___ 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
Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library
I thought there was now an option the boost build system to NOT add
all the "very specific" naming of each library which is now the
default. There is a way to turn that back on. You will have to search
through the boost-build docs for that info.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Mar 18, 2010, at 9:47 AM, Marcel Loose wrote:
Hi all,
I ran into a problem with FindBoost where it fails to find the correct
version of a component library. The cause is pretty clear to me.
There's a system-wide (rather old) version of Boost installed and
there's my latest-greatest version of Boost. The FindBoost macro
searches for a library using rather specific names first and generic
names last. These are all listed under NAMES. FIND_LIBRARY() tries to
find each name in all paths specified under PATHS.
Problem is that (for reasons I do not really know) the very specific
library name is not present in my latest-greatest directory, but it IS
present in /usr/lib.
This problem is closely related to a post on this list a couple of
months ago: http://www.mail-archive.com/cmake@cmake.org/msg24565.html
Unfortunately, no-one ever replied to that post.
Basically, the author of that post suggested to turn the loop in
cmFindLibraryCommand::FindNormalLibrary() inside out: i.e.
for(path in paths)
{
for(name in names)
{
find name in path;
if found return name;
}
}
Any thoughts on this?
Best regards,
Marcel Loose.
___
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
___
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
