[context] asm_context_sources breaking regression testing for WinCE
Hi Oliver, I finally got a little bit of time to investigate recent strange behavior on the VeecoFTC regression tester and found that the build jamfile for the context library is halting Boost.Build during the regression tests. It appears that, when it can't find an appropriate architecture to use, it actually generates an argument error in try-one-generator-really. I attached the output of the bjam.log and perhaps it will be useful for investigating. Let me know if you would like me to try anything. Thanks, -Dave
Hello Dave,
I finally got a little bit of time to investigate recent strange behavior on the VeecoFTC regression tester and found that the build jamfile for the context library is halting Boost.Build during the regression tests. It appears that, when it can't find an appropriate architecture to use, it actually generates an argument error in try-one-generator-really. I attached the output of the bjam.log and perhaps it will be useful for investigating. Let me know if you would like me to try anything.
cross-compiling is a little bit problematic. Please note that Windows CE on ARM is not supported yet (if I find time I'll implement the calling conventions for this platform). File libs/context/config/x86.cpp identifies the x86 architecture (your cross-compiler environment is required to simulate WinCE on x86). x86.cpp contains macros defined by several compilers for x86. Regarding to http://msdn.microsoft.com/en-us/library/aa449784.aspx Windows CE defines _M_IX86 for this purpose - but this macro is already contained by x86.cpp - therefore I assume that your cross-compiler env. is not correct/complete. Maybe you can write a little test-app checking for this macro: #include <iostream> int main( int argc, char * argv[]) { #if defined (_M_IX86) std::cout << "_M_IX86 defined\n"; #else std::cout << "_M_IX86 not defined\n"; #endif return 0; } regards, Oliver
On 12/2/2012 3:17 AM, Oliver Kowalke wrote:
Hello Dave,
I finally got a little bit of time to investigate recent strange behavior on the VeecoFTC regression tester and found that the build jamfile for the context library is halting Boost.Build during the regression tests. It appears that, when it can't find an appropriate architecture to use, it actually generates an argument error in try-one-generator-really. I attached the output of the bjam.log and perhaps it will be useful for investigating. Let me know if you would like me to try anything.
Maybe you can write a little test-app checking for this macro:
#include <iostream>
int main( int argc, char * argv[]) { #if defined (_M_IX86) std::cout << "_M_IX86 defined\n"; #else std::cout << "_M_IX86 not defined\n"; #endif
return 0; }
The _M_IX86 is not defined. However, I am actually less concerned about whether or not Boost.Context is functional on WinCE/ARM. What doesn't seem right is that Boost.Context is aborting the entire regression test sequence by generating a run-time error in the jamfile. I would expect that if Boost.Context does not know which asm files to build for a certain platform, then it would fail gracefully and allow the regression test script to move on to other tests for other libraries. At the moment, the VeecoFTC regresssion tester is now unable to reliably test any libraries because of the way that the Boost.Context jamfile handles this problem. Thanks, -Dave
The _M_IX86 is not defined. do you compile for ARM vor X86?
However, I am actually less concerned about whether or not Boost.Context is functional on WinCE/ARM. What doesn't seem right is that Boost.Context is aborting the entire regression test sequence by generating a run-time error in the jamfilile.
the jam file dos not special things, it provides only the alternatives. you can specify --without-context in order to exclude context from build.
On 12/2/2012 10:10 AM, Oliver Kowalke wrote:
The _M_IX86 is not defined. do you compile for ARM vor X86?
However, I am actually less concerned about whether or not Boost.Context is functional on WinCE/ARM. What doesn't seem right is that Boost.Context is aborting the entire regression test sequence by generating a run-time error in the jamfilile.
the jam file dos not special things, it provides only the alternatives. you can specify --without-context in order to exclude context from build.
This problem is actually occurring as part of the automated trunk regression testing, not a local build, so it is slightly more inconvenient to specifically exclude this library from the test suite. However, I think there is a fairly simple fix to allow the build of Boost.Context to fail gracefully in the event that the architecture is unsupported. Supplying a default 'fall back' alias for asm_context_sources to be used when no other alias matches should keep the Boost.Build file from throwing an hard error. Please see the attached patch. Thanks, -Dave
other unsupported platforms like Itanium gracefully fail - your build env is broken because you build WinCE for x86 but _M_X86 is not defined (but MSDN describes that it should - see link in my previous post). Am 03.12.2012 05:24 schrieb "David Deakins" <ddeakins@veeco.com>:
On 12/2/2012 10:10 AM, Oliver Kowalke wrote:
The _M_IX86 is not defined.
do you compile for ARM vor X86?
However, I am actually less concerned about whether or not Boost.Context
is functional on WinCE/ARM. What doesn't seem right is that Boost.Context is aborting the entire regression test sequence by generating a run-time error in the jamfilile.
the jam file dos not special things, it provides only the alternatives. you can specify --without-context in order to exclude context from build.
This problem is actually occurring as part of the automated trunk regression testing, not a local build, so it is slightly more inconvenient to specifically exclude this library from the test suite.
However, I think there is a fairly simple fix to allow the build of Boost.Context to fail gracefully in the event that the architecture is unsupported. Supplying a default 'fall back' alias for asm_context_sources to be used when no other alias matches should keep the Boost.Build file from throwing an hard error. Please see the attached patch.
Thanks, -Dave
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 12/3/2012 12:41 AM, Oliver Kowalke wrote:
other unsupported platforms like Itanium gracefully fail - your build env is broken because you build WinCE for x86 but _M_X86 is not defined (but MSDN describes that it should - see link in my previous post).
Actually that regression test platform is for Windows Mobile 5 which is an ARMv4i build. So I think it is correct that the _M_X86 flag is not defined. It's not clear to me why you are reluctant to provide the fallback alias for situations like this where the existing set of aliases fail to match anything. Do you have a specific concern about this method? Also if you have any alternative way to make the build jamfile more robust in this situation, I am not picky about this approach. Thanks, -Dave
2012/12/3 David Deakins <ddeakins@veeco.com>
On 12/3/2012 12:41 AM, Oliver Kowalke wrote:
other unsupported platforms like Itanium gracefully fail - your build env is broken because you build WinCE for x86 but _M_X86 is not defined (but MSDN describes that it should - see link in my previous post).
Actually that regression test platform is for Windows Mobile 5 which is an ARMv4i build. So I think it is correct that the _M_X86 flag is not defined.
OK
It's not clear to me why you are reluctant to provide the fallback alias for situations like this where the existing set of aliases fail to match anything. Do you have a specific concern about this method? Also if you have any alternative way to make the build jamfile more robust in this situation, I am not picky about this approach.
I don't like the idea to add a dummy cpp-file. I tried to use <build>no but without success. I'm still wondering why on of your test systems (9.0~wm5~stlport5.2 == Windows CE 5 ?) gracefully fails (with message 'platform not supported') and the other one does fail without any information (at least at thre regression test page). Does bjam segfault or do you get some output/warnings/errors? I've removed an unreferenced alias from Jamfile.v2 - but it would be suspicious if this would have caused the error.
On 12/3/2012 7:09 AM, Oliver Kowalke wrote:
I'm still wondering why on of your test systems (9.0~wm5~stlport5.2 == Windows CE 5 ?) gracefully fails (with message 'platform not supported') and the other one does fail without any information (at least at thre regression test page). Does bjam segfault or do you get some output/warnings/errors? I've removed an unreferenced alias from Jamfile.v2 - but it would be suspicious if this would have caused the error.
That was actually a good clue. The 9.0~wm5~stlport5.2 platform is the Windows Mobile 5 ARM platform (not CE 5 on x86) and that compile on Nov 28 was the last time that the build worked. It appears that the changes you checked in on Nov 27 (and which didn't get picked up until after Nov 28 on the regression test builds) caused things to stop working. It looks like when you had the additional context_sources target with fcontext.cpp, then it would fail to select an alias for select_asm_context, but it would still see fcontext.cpp for the source of lib boost_context. And so it was still happy and would compile fcontext.cpp and move on. Then during the Boost.Context test builds it would gracefully fail with the 'platform not supported' message you see in the test output. However, after the jamfile changes of Nov 27 that eliminated context_sources, now when it fails to match any of the asm_context_sources aliases, it ends up that lib boost_context has no sources at all for that first argument and this seems to make Boost.Build angry (see the argument error messages back in the attachment from my earlier post). So it seems like the trouble is making sure there is at least some source file to build in the event that the platform is not supported and that no alias of asm_context_sources is matched. Or maybe there is some other Boost.Build mechanism to realize that the platform is not supported and block it from trying to build lib boost_context at all. Thanks, -Dave
Hello David, thank you for your help - I've modified boost.context and committed the changes to boost-trunk (Revision 81698). best regards, Oliver
On 12/3/2012 12:24 PM, Oliver Kowalke wrote:
Hello David, thank you for your help - I've modified boost.context and committed the changes to boost-trunk (Revision 81698).
Thanks! I'll kick off another regression test cycle and confirm that everything is happy now. -Dave
Seems not to work - I assume that the properties mach some entries for ARM in the Jamfile (probably it ELF is assumed). would it be possible that you send be the complete output of: bjam toolset=msvc --debug-building I could figure out which properties are set (for instance <target-os> and os.name etc.) thx, Oliver 2012/12/3 David Deakins <ddeakins@veeco.com>
On 12/3/2012 12:24 PM, Oliver Kowalke wrote:
Hello David, thank you for your help - I've modified boost.context and committed the changes to boost-trunk (Revision 81698).
Thanks! I'll kick off another regression test cycle and confirm that everything is happy now.
-Dave
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
On 12/6/2012 12:42 PM, Oliver Kowalke wrote:
Seems not to work - I assume that the properties mach some entries for ARM in the Jamfile (probably it ELF is assumed). would it be possible that you send be the complete output of: bjam toolset=msvc --debug-building I could figure out which properties are set (for instance <target-os> and os.name etc.)
I saw that it was selecting unsupported.cpp and generating the #error on the first run of tests after the change, but you are correct that it seems not to have selected this alias on the lastest run. You may be right that it is now matching to the newer ARM stuff. However, it is not preventing tests of other libraries from running, which was the earlier problem, so that is good. (Although a different issue with test output path names on a few libraries getting beyond the 256 character limit is now causing this problem, but I am working on it separately). Thanks, -Dave
participants (2)
-
David Deakins -
Oliver Kowalke