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
On Mon, Mar 22, 2010 at 4:05 AM, Marcel Loose lo...@astron.nl 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
On Fri, Mar 19, 2010 at 10:22 AM, Chuck Atkins chuck.atk...@kitware.com 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
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
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
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
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
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
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.
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
10 matches
Mail list logo
