[all/build] Build change that affects testers...
All, Some time ago the following problem surfaced: Robert Ramey wrote:
Almost all the tests for the serialization system fail to link with the following message:
### mwld Linker Error: # Undefined symbol: '_errno' # referenced from 'void boost::unit_test::hrf_report_formatter::report_assertions_stat(class std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, unsigned long, unsigned long, unsigned long)
(?report_assertions_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$basi
c_ostream@DU?$char_traits@D@std@@@std@@IKKK@Z)' in unit_test_result.obj (libboost_test_exec_monitor.lib) ### mwld Linker Error: # Undefined symbol: '_errno' # referenced from 'void boost::unit_test::hrf_report_formatter::report_sub_test_cases_stat(class std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, unsigned long, unsigned long)
basic_ostream@DU?$char_traits@D@std@@@std@@IKK@Z)' in unit_test_result.obj (libboost_test_exec_monitor.lib)
Errors caused tool to abort.
To me, this suggests some issue regarding
(?report_sub_test_cases_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$ libboost_test_exec_monitor.lib .
Anyone care to comment?
I spent most of yesterday and today trying to figure this problem out. What it boiled down to was the "errno" use in the std::log10 function. But that wasn't the real problem... The reason it gives the above error is that when building certain tests like serialization and threads the library was using the multi-threaded runtime while the Boost.Test was using single-threaded runtime. Which needles to say is a very bad thing of the build system to do. Much time later I managed to track down the problem in the build system and fix. Now, the *important* part... This change will affect all platforms that use multiple runtimes. As far as I know this includes all Win32 compilers. So don't be surprised if the next run of regression tests take a long time and more disk space, because different variants of things will get compiled now. And if you are really paranoid about testing, you might be advised to delete the "bin/boost" build directory to start fresh. Enjoy -- the corrected functionality ;-) PS. I'm starting a fresh run of the CW-8.3/release tests now. Which should show a large number of fixed failures. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
[...]
I spent most of yesterday and today trying to figure this problem out. What it boiled down to was the "errno" use in the std::log10 function. But that wasn't the real problem... The reason it gives the above error is that when building certain tests like serialization and threads the library was using the multi-threaded runtime while the Boost.Test was using single-threaded runtime. Which needles to say is a very bad thing of the build system to do. Much time later I managed to track down the problem in the build system and fix.
[...]
Thanks for your efforts! What is the "common" runtime they are using now? Is it single or multithreaded or is it the one specified for the test case? There is one point which gets more and more important for me: What about potential differences between release/debug or single/multithreaded configurations? Shouldn't we run tests for all of them? Stefan
Stefan Slapeta wrote:
Rene Rivera wrote:
[...]
I spent most of yesterday and today trying to figure this problem out. What it boiled down to was the "errno" use in the std::log10 function. But that wasn't the real problem... The reason it gives the above error is that when building certain tests like serialization and threads the library was using the multi-threaded runtime while the Boost.Test was using single-threaded runtime. Which needles to say is a very bad thing of the build system to do. Much time later I managed to track down the problem in the build system and fix.
[...]
Thanks for your efforts! What is the "common" runtime they are using now? Is it single or multithreaded or is it the one specified for the test case?
It's the one required by the test. In the case of Boost.Thread tests it's both multi-threaded-static-link and multi-threaded-dynamic-link. The bug was that the test would specify those but the libraries would specify another and the Boost.Build was not correctly imposing the one the test wanted.
There is one point which gets more and more important for me: What about potential differences between release/debug or single/multithreaded configurations? Shouldn't we run tests for all of them?
We probably should, and for cw-8.3 we do. Metacomm runs the usual debug versions, which includes single and multi threaded. While the ones I run are release. And what I would suggest is that for people that are running "duplicate" tests. To coordinate to have some run debug and others release. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
We probably should, and for cw-8.3 we do. Metacomm runs the usual debug versions, which includes single and multi threaded. While the ones I run are release.
And what I would suggest is that for people that are running "duplicate" tests. To coordinate to have some run debug and others release.
I could also run my tests (Intel 8, CW 9.3) in release mode on another machine if somebody could tell me the easiest way to configure that. (I guess the default is debug, is that right?) Cheers, Stefan
Stefan Slapeta wrote:
Rene Rivera wrote:
We probably should, and for cw-8.3 we do. Metacomm runs the usual debug versions, which includes single and multi threaded. While the ones I run are release.
And what I would suggest is that for people that are running "duplicate" tests. To coordinate to have some run debug and others release.
I could also run my tests (Intel 8, CW 9.3) in release mode on another machine if somebody could tell me the easiest way to configure that. (I guess the default is debug, is that right?)
Debug is the default. If you have your own script just adding -sBUILD=release should do it. If you are using the regression.py script it looks like you should be able to add: --bjam-options=-sBUILD=release --grafik
Rene Rivera wrote:
Debug is the default. If you have your own script just adding -sBUILD=release should do it. If you are using the regression.py script it looks like you should be able to add: --bjam-options=-sBUILD=release
Running! Results should be online tomorrow. Cheers, Stefan
participants (4)
-
Bronek Kozicki -
Rene Rivera -
Stefan Slapeta -
Stefan Slapeta