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
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 fro
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 definit
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 vers
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)
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
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
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
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.
_
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
10 matches
Mail list logo
