Re: [boost] Running b2 on develop needs asynch-exceptions=on

Subject: Re: [boost] Running b2 on develop needs asynch-exceptions=on
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2015-03-17 01:59:52

On 03/16/2015 11:24 PM, Raffi Enficiaud wrote:
> Le 16/03/15 17:51, Vladimir Prus a écrit :
>> On 03/16/2015 03:19 PM, John Maddock wrote:
>>> I'm not at all sure this is the right fix: I believe Boost.Test really
>>> does need asynch-exception support turned on to work it's magic.
>>
>> In that thread, Gennadiy say it does not need that from Boost.System,
>> that it only needs client to set that. It's not quite clear
>> whether Boost.Test itself should be built with that or not.
>
> This is not exactly what I understood from
> "I am sure execution_monitor.cpp needs it." (http://lists.boost.org/Archives/boost/2015/03/220493.php)

Steven's analysis suggests it's not really needed, on develop, except for VS 2003, which we probably can
ignore.

>>
>> Anyway, my primary point, if you allow a bit of ranting, is that it's
>> clearly Boost.Test that tries to use custom
>> settings that cause issues, but the people who appear to care most are
>> Jürgen and Paul and you and I, neither of
>> whom are Boost.Test maintainers. That's not really productive. So with
>> this change, it's up to Boost.Test maintainers to do
>> whatever is right, which might be updating documentation, or using just
>> explicit /EHa cflags, or something else.
>
> It looks to me that now several libraries are trying to do that as well, and to me everything is related to the fact that, at some point, a
> chain of dependency reaches boost.system with different and conflicting options.
> So even if a user code uses boost.test in header mode (in order to have its options handled properly), this code would link at some point
> with boost.system with potentially conflicting options.
>
> This lead me to think that the issue is not only related to boost.test, but rather in any compiled library that would be linked against a
> client code with specific options conflicting with boost.system. The case of boost.test is just an example of the client code that might use
> boost.system.
> Or maybe I am missing something there?

There's a indeed a generic constraint here - if an application A uses boost libraries B and C and both of those use boost library D,
then either library D should be built with particular set of option, or application A will have two copies of D - either via statically
linking two copies of it, or dynamically linking to two shared libraries with different names. The options with two copies look like
formal ODR violation, and something rather risky in practice.

Given this generic constraint, Boost.Test is the library that tries to violate it, on devel, right now.

(FAOD, it's very different from earlier Boost.Context issue, where we ran into a limitation of Boost.Build, not anything
actually relevant).

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com