Running b2 on develop needs asynch-exceptions=on
After a recent pull of develop branch, I found that I also need to add asynch-exceptions=on to avoid a failure to build error: Tried to build the target twice, with property sets having error: these incompatible properties:
error: - <asynch-exceptions>off error: - <asynch-exceptions>on
(This is in addition to needing address-model=32 architecture=x86) b2 address-model=32 architecture=x86 asynch-exceptions=on I wasn't clear if this thread had come to a conclusion? [boost] [test] Re: Conflicts when building libraries at root http://lists.boost.org/Archives/boost/2015/03/220552.php looks as though a fix is still needed? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 03/16/2015 01:08 PM, Paul A. Bristow wrote:
After a recent pull of develop branch, I found that I also need to add asynch-exceptions=on to avoid a failure to build
error: Tried to build the target twice, with property sets having error: these incompatible properties:
error: - <asynch-exceptions>off error: - <asynch-exceptions>on
(This is in addition to needing address-model=32 architecture=x86)
b2 address-model=32 architecture=x86 asynch-exceptions=on
I wasn't clear if this thread had come to a conclusion?
[boost] [test] Re: Conflicts when building libraries at root
http://lists.boost.org/Archives/boost/2015/03/220552.php
looks as though a fix is still needed?
Since I did not get a response, I went ahead removing all <asynch-exceptions>on from Boost.Test Jamfile, and pushed to devel branch. Could you give it a try? Should further changes be needed, they can be done at later time - subject to keeping top-level build with no options working. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
http://lists.boost.org/Archives/boost/2015/03/220552.php
looks as though a fix is still needed?
Since I did not get a response, I went ahead removing all <asynch-exceptions>on from Boost.Test Jamfile, and pushed to devel branch. Could you give it a try?
Should further changes be needed, they can be done at later time - subject to keeping top-level build with no options working.
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. John.
On 03/16/2015 03:19 PM, John Maddock wrote:
http://lists.boost.org/Archives/boost/2015/03/220552.php
looks as though a fix is still needed?
Since I did not get a response, I went ahead removing all <asynch-exceptions>on from Boost.Test Jamfile, and pushed to devel branch. Could you give it a try?
Should further changes be needed, they can be done at later time - subject to keeping top-level build with no options working.
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. 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. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 16 March 2015 16:51 To: boost@lists.boost.org Subject: Re: [boost] Running b2 on develop needs asynch-exceptions=on
On 03/16/2015 03:19 PM, John Maddock wrote:
http://lists.boost.org/Archives/boost/2015/03/220552.php
looks as though a fix is still needed?
Since I did not get a response, I went ahead removing all <asynch-exceptions>on from Boost.Test Jamfile, and pushed to devel branch. Could you give it a
Should further changes be needed, they can be done at later time - subject to keeping top-level build with no options working.
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.
Anyway, my primary point, if you allow a bit of ranting, is that it's clearly Boost.Test that
try? 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.
I'm exceptionally confused, but if I have zillions of VC project files which assume test is built with /EHa, then I assume I need the Boost.Test library built with /EHa. (unless I change them all and/or lose some of Boost.Test functionality - none of which are attractive). I also suspect that I am not alone in this desire. What I have done (explicit <asynch-exceptions>on) seems to work. So do we need to just update the docs? But it had better be in VERY BIG LETTERS because it would be a breaking change for very many users? I'm the only one shouting because I'd had to rebuild after a GIT glitch, but there be many others to follow? Has the Boost.Test library actually changed? HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul A. Bristow wrote:
What I have done (explicit <asynch-exceptions>on) seems to work.
This builds the whole Boost with /EHa. You're perfectly within your rights to do so, of course, but I'd rather not, and I don't think that this should be the default. It makes no sense for applications that don't use Boost.Test, for example. (Correctness considerations aside, I suspect that this will also cause quite a penalty in cases where the compiler can no longer remove try/catch(...) blocks when it sees that the code inside can't throw, and those aren't uncommon in generic code such as the implementation of std::vector.)
On 03/16/2015 09:23 PM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 16 March 2015 16:51 To: boost@lists.boost.org Subject: Re: [boost] Running b2 on develop needs asynch-exceptions=on
On 03/16/2015 03:19 PM, John Maddock wrote:
http://lists.boost.org/Archives/boost/2015/03/220552.php
looks as though a fix is still needed?
Since I did not get a response, I went ahead removing all <asynch-exceptions>on from Boost.Test Jamfile, and pushed to devel branch. Could you give it a
try?
Should further changes be needed, they can be done at later time - subject to keeping top-level build with no options working.
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.
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.
I'm exceptionally confused, but if I have zillions of VC project files which assume test is built with /EHa, then I assume I need the Boost.Test library built with /EHa.
(unless I change them all and/or lose some of Boost.Test functionality - none of which are attractive).
I also suspect that I am not alone in this desire.
What I have done (explicit <asynch-exceptions>on) seems to work. So do we need to just update the docs? But it had better be in VERY BIG LETTERS because it would be a breaking change for very many users? I'm the only one shouting because I'd had to rebuild after a GIT glitch, but there be many others to follow?
It probably builds, but then Peter has said that building all of Boost with asynch-exceptions is a bad idea. I still haven't got an authorative answer whether it should be Boost.Test that builds with /EHa (so that it can catch SEH exception), or whether client code with tests be built with /EHa (so that it converts SEH exceptions into C++ exceptions) or something else. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
It probably builds, but then Peter has said that building all of Boost with asynch-exceptions is a bad idea.
I still haven't got an authorative answer whether it should be Boost.Test that builds with /EHa (so that it can catch SEH exception), or whether client code with tests be built with /EHa (so that it converts SEH exceptions into C++ exceptions) or something else.
I suspect both. Certainly if I build Boost.Test without /EHa I see: execution_monitor.cpp 1>m:\data\boost\boost\boost\test\impl\execution_monitor.ipp(948): warning C4535: calling _set_se_translator() requires /EHa Then if you want it to translate structured exceptions in your test code you'll need /EHa there as well presumably. Non-authoritatively yours, John.
John Maddock <jz.maddock <at> googlemail.com> writes:
I still haven't got an authorative answer whether it should be Boost.Test that builds with /EHa (so that it can catch SEH exception), or whether client code with tests be built with /EHa (so that it converts SEH exceptions into C++ exceptions) or something else.
I suspect both. Certainly if I build Boost.Test without /EHa I see:
execution_monitor.cpp 1>m:\data\boost\boost\boost\test\impl\execution_monitor.ipp(948): warning C4535: calling _set_se_translator() requires /EHa
Then if you want it to translate structured exceptions in your test code you'll need /EHa there as well presumably.
This is my understanding as well. We do not really care as much about /EHa in libraries UTF depends on. Unless someone from MS dev team can contradict this, I believe this is what we need. As far as I know Boost.Build and according to my recollection, this is was an intention form the very beginning. Clients were required to be build with /EHa as well and that is enforced through the requirements section in Boost.Build rule. Gennadiy
AMDG On 03/16/2015 12:41 PM, Vladimir Prus wrote:
I still haven't got an authorative answer whether it should be Boost.Test that builds with /EHa (so that it can catch SEH exception), or whether client code with tests be built with /EHa (so that it converts SEH exceptions into C++ exceptions) or something else.
I've looked through the Boost.Test source, and I /think/ that Boost.Test does not need to be built with /EHa. /EHa has two effects: a) catch(...) will handle SEH exceptions. Boost.Test uses __try/__except, so this shouldn't matter. b) SEH exceptions will unwind the stack properly. As far as I can tell, Boost.Test itself doesn't put anything critical on the stack before calling into user code. In Christ, Steven Watanabe
I've looked through the Boost.Test source, and I /think/ that Boost.Test does not need to be built with /EHa.
/EHa has two effects: a) catch(...) will handle SEH exceptions. Boost.Test uses __try/__except, so this shouldn't matter. b) SEH exceptions will unwind the stack properly. As far as I can tell, Boost.Test itself doesn't put anything critical on the stack before calling into user code.
What about the warning from execution_monitor.cpp saying that /EHa *is* required? John.
Le 16/03/15 20:40, Steven Watanabe a écrit :
AMDG
On 03/16/2015 01:21 PM, John Maddock wrote:
What about the warning from execution_monitor.cpp saying that /EHa *is* required?
Is this on master or develop? On develop _set_se_translator is guarded by #if BOOST_WORKAROUND(BOOST_MSVC, <= 1310)
In Christ, Steven Watanabe
Hi This is also the point to which we got with Gennadiy. Since we cannot be sure, we did not made any change until we can create appropriate tests for these kind of exceptions. The _set_se_translator definitely needs /EHa, but MSVC 1310 is Visual 2003 sp1, and I believe that there is no test agent for that compiler anymore. The MSDN documentation (https://msdn.microsoft.com/en-us/library/1deeycx5.aspx) states that managed code needs /EHa. This is a valid use of boost.test. To my understanding it also means that removing this option would break the currently existing test using managed code to work properly with the boost.test that is built out of the box. Regards, Raffi Enficiaud
AMDG On 03/16/2015 02:06 PM, Raffi Enficiaud wrote:
The MSDN documentation (https://msdn.microsoft.com/en-us/library/1deeycx5.aspx) states that managed code needs /EHa. This is a valid use of boost.test. To my understanding it also means that removing this option would break the currently existing test using managed code to work properly with the boost.test that is built out of the box.
I think this is unavoidable if you depend on Boost.System. Wouldn't Boost.System need to be built with /EHa as well? We definitely shouldn't build all of Boost with /EHa by default. In Christ, Steven Watanabe
Le 16/03/15 21:21, Steven Watanabe a écrit :
AMDG
On 03/16/2015 02:06 PM, Raffi Enficiaud wrote:
The MSDN documentation (https://msdn.microsoft.com/en-us/library/1deeycx5.aspx) states that managed code needs /EHa. This is a valid use of boost.test. To my understanding it also means that removing this option would break the currently existing test using managed code to work properly with the boost.test that is built out of the box.
I think this is unavoidable if you depend on Boost.System. Wouldn't Boost.System need to be built with /EHa as well? We definitely shouldn't build all of Boost with /EHa by default.
In Christ, Steven Watanabe
I agree that this is unavoidable. So the proposal here is to have the option "aynch-exception-on" visible and make the user be able to set it?
On 03/17/2015 12:44 AM, Raffi Enficiaud wrote:
Le 16/03/15 21:21, Steven Watanabe a écrit :
AMDG
On 03/16/2015 02:06 PM, Raffi Enficiaud wrote:
The MSDN documentation (https://msdn.microsoft.com/en-us/library/1deeycx5.aspx) states that managed code needs /EHa. This is a valid use of boost.test. To my understanding it also means that removing this option would break the currently existing test using managed code to work properly with the boost.test that is built out of the box.
I think this is unavoidable if you depend on Boost.System. Wouldn't Boost.System need to be built with /EHa as well? We definitely shouldn't build all of Boost with /EHa by default.
In Christ, Steven Watanabe
I agree that this is unavoidable. So the proposal here is to have the option "aynch-exception-on" visible and make the user be able to set it?
It's just an ordinary feature that the user can set on command line with b2 asynch-exceptions=on -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
On 03/16/2015 01:21 PM, Steven Watanabe wrote:
AMDG
On 03/16/2015 02:06 PM, Raffi Enficiaud wrote:
The MSDN documentation (https://msdn.microsoft.com/en-us/library/1deeycx5.aspx) states that managed code needs /EHa. This is a valid use of boost.test. To my understanding it also means that removing this option would break the currently existing test using managed code to work properly with the boost.test that is built out of the box.
I think this is unavoidable if you depend on Boost.System. Wouldn't Boost.System need to be built with /EHa as well? We definitely shouldn't build all of Boost with /EHa by default.
Would adding a usage-requirement to Boost.Test resolve this? Only targets that use Boost.Test would compile with the asynch-exceptions flag turned 'on'. -- Michael Caisse ciere consulting ciere.com
On Monday 16 March 2015 14:49:51 Michael Caisse wrote:
On 03/16/2015 01:21 PM, Steven Watanabe wrote:
AMDG
On 03/16/2015 02:06 PM, Raffi Enficiaud wrote:
The MSDN documentation (https://msdn.microsoft.com/en-us/library/1deeycx5.aspx) states that managed code needs /EHa. This is a valid use of boost.test. To my understanding it also means that removing this option would break the currently existing test using managed code to work properly with the boost.test that is built out of the box.
I think this is unavoidable if you depend on Boost.System. Wouldn't Boost.System need to be built with /EHa as well? We definitely shouldn't build all of Boost with /EHa by default.
Would adding a usage-requirement to Boost.Test resolve this? Only targets that use Boost.Test would compile with the asynch-exceptions flag turned 'on'.
I don't think this is correct either. There are tests which do not require /EHa and also depend on multiple different compiled libraries including Test (e.g. tests in Thread, Log) and eventually on System as well. I'm sure most, if not all of these tests don't care about SEH and expect normal C++ exceptions semantics. I think, async exceptions are a very special requirement which has to be expressed by the end user of the libraries - i.e. the test or user's application, if it uses Boost.Build, or the user himself when he builds Boost. By default Boost should be built with normal C++ exceptions. Yes, this means people who use managed C++ or need stack unwinding during SEH will have to build Boost themselves.
AMDG On 03/16/2015 09:59 PM, Andrey Semashev wrote:
I don't think this is correct either. There are tests which do not require /EHa and also depend on multiple different compiled libraries including Test (e.g. tests in Thread, Log) and eventually on System as well. I'm sure most, if not all of these tests don't care about SEH and expect normal C++ exceptions semantics.
I think, async exceptions are a very special requirement which has to be expressed by the end user of the libraries - i.e. the test or user's <snip>
Boost.Test uses SEH to give better errors when the test program crashes. In Christ, Steven Watanabe
Raffi Enficiaud <raffi.enficiaud <at> mines-paris.org> writes:
The MSDN documentation (https://msdn.microsoft.com/en-
us/library/1deeycx5.aspx) states that
managed code needs /EHa.
It also states that /EHa is the default for managed code, so it doesn't have to be specified explicitly.
Le 16/03/15 21:34, Marcel Raad a écrit :
Raffi Enficiaud <raffi.enficiaud <at> mines-paris.org> writes:
The MSDN documentation (https://msdn.microsoft.com/en-
us/library/1deeycx5.aspx) states that
managed code needs /EHa.
It also states that /EHa is the default for managed code, so it doesn't have to be specified explicitly.
... for the managed part. Yet the code that would catch those exceptions should be compiled with /EHa (again to my understanding).
AMDG On 03/16/2015 01:21 PM, John Maddock wrote:
What about the warning from execution_monitor.cpp saying that /EHa *is* required?
It isn't required. First of all, _set_se_translator requires /EHa at the /catch/ site, not when it is called. If /EHa is not enabled at the catch site, _set_se_translator has no effect. Boost.Test only uses _set_se_translator to neutralize one of the effects of /EHa, so it's actually perfectly okay. In Christ, Steven Watanabe
Am 17.03.2015 um 19:18 schrieb Steven Watanabe:
What about the warning from execution_monitor.cpp saying that /EHa *is* required?
It isn't required. First of all, _set_se_translator requires /EHa at the /catch/ site, not when it is called. If /EHa is not enabled at the catch site, _set_se_translator has no effect. Boost.Test only uses _set_se_translator to neutralize one of the effects of /EHa, so it's actually perfectly okay.
Exactly. I've been using _set_se_translator in various projects in the past and I never had to build with /EHa except for the tiny fraction of code at the catch site. C++ exceptions are nothing but Windows structured exceptions with a special tag. Therefore it doesn't matter at all which build option is used at the throw site. You can even get away without the /EHa and _set_se_translator shebang if you stick with __try/__except and cast the exception info into a std::exception_ptr or do whatever else you have to. Ciao Dani
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)
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? Best, Raffi PS.: sorry for not being pro-active in the list, but neither Gennadiy nor myself came up with a clear status on this issue.
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
participants (11)
-
Andrey Semashev -
Daniela Engert -
Gennadiy Rozental -
John Maddock -
Marcel Raad -
Michael Caisse -
Paul A. Bristow -
Peter Dimov -
Raffi Enficiaud -
Steven Watanabe -
Vladimir Prus