On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get
error: Name clash for 'libboost_system-vc80-mt-gd-1_58.lib'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - <warnings>all
error: - <address-model>32 <architecture>x86 <warnings>on
When I add --without-context --without-coroutine, I now get
error: Name clash for 'libboost_system-vc80-mt-1_58.lib'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - <asynch-exceptions>off
error: - <asynch-exceptions>on
So I add --without-test.
error: Name clash for 'libboost_timer-vc80-mt-1_58.lib'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - <asynch-exceptions>on <library>object(file-target)@10959
error: - <asynch-exceptions>off <library>object(file-target)@9953
Now where did _that_ come from. :-)
Ah. --without-endian. Builds now.
This is perhaps old news for some, but it looks like it doesn't play well
with our simple build instructions. Or maybe it doesn't occur on the master
branch, so we don't care? I haven't checked yet.
It's also perhaps an indication of a deeper problem. I can use
b2 --with-test and have 'test' built; it builds its dependencies (system,
chrono and timer) with <asynch-exceptions>on in bin.v2, and if I use it from
within Boost.Build, it will link to them. But if I stage (or install)
Boost.Test, and then stage or install Boost.System separately, Boost.System
will be built with <asynch-exceptions>off. So the library user who just has
headers and binaries will link those, potentially creating a conflict, which
may in this case be benign. Or not.
