boost_unit_test_framework cannot be built as DLL with msvc-6.5
I am trying to get the regressions straight for msvc-6.5. I discovered, that some of the test's test are failing with msvc-6.5. I tracked this down to the fact, that the boost_unit_test_framework cannot be built as a DLL. In fact the compilation of compiler_log_formatter faults with error C2504 : test_suite : base class undefined altough the base class is being properly declared. I suspect that the problem is, that the base class contains some template classes which are not exported. Trying to export them unfortunately doesn't resolve the problem. I further suspect, that it isn't possible to export templated classes with msvc-6.5. But I am not sure on that. Is this a known issue? Are there any work-arounds possible? If not: 1) Should the tests be omitted for msvc-6.5? 2) Are other boost regression test affected? Roland
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:45BE5655.7040102@chello.at...
I am trying to get the regressions straight for msvc-6.5. I discovered, that some of the test's test are failing with msvc-6.5.
I tracked this down to the fact, that the boost_unit_test_framework cannot be built as a DLL.
Boost.Test doesn't support DLLs for msvc 6.5. And have no plans for this to change. Gennadiy
Gennadiy Rozental wrote:
Boost.Test doesn't support DLLs for msvc 6.5. And have no plans for this to change.
So what? Some of the test tests are explicitly making use of DLL's. Should these simply omitted for msvc-6.5? Shall I try to modify the Jamfile? Then I think I almost racked down from where the error comes: It seems that the compiler does not allow to embed a member callback0<> m_callbackfn; in an exported class. I assume that this callback is across DLL boundaries, yes? Perhaps someone with knowledge of the inner workings of Boost.Test can suggest a work around? Roland
Roland Schwarz ha escrito:
Gennadiy Rozental wrote:
Boost.Test doesn't support DLLs for msvc 6.5. And have no plans for this to change.
So what? Some of the test tests are explicitly making use of DLL's. Should these simply omitted for msvc-6.5? Shall I try to modify the Jamfile?
Then I think I almost racked down from where the error comes:
It seems that the compiler does not allow to embed a member callback0<> m_callbackfn; in an exported class. I assume that this callback is across DLL boundaries, yes? Perhaps someone with knowledge of the inner workings of Boost.Test can suggest a work around?
Hello Roland, Seems like using (for MSVC 6.0 alone) a shared_ptr<callback0<> > rather than directly a callback0<> could make things work. I've patched boost/test/unit_test_suite_impl.hpp and boost/test/impl/unit_test_suite.ipp (attached) to implement this idea and looks like, with much effort, at least it passes the compiling stage, but I don't have time to do a full build and run the tests. Maybe you can do this? Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo // (C) Copyright Gennadiy Rozental 2005. // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // See http://www.boost.org/libs/test for the library home page. // // File : $RCSfile: unit_test_suite.ipp,v $ // // Version : $Revision: 1.13 $ // // Description : privide core implementation for Unit Test Framework. // Extensions could be provided in separate files // *************************************************************************** #ifndef BOOST_TEST_UNIT_TEST_SUITE_IPP_012205GER #define BOOST_TEST_UNIT_TEST_SUITE_IPP_012205GER // Boost.Test #include <boost/detail/workaround.hpp> #include <boost/test/unit_test_suite_impl.hpp> #include <boost/test/framework.hpp> #include <boost/test/utils/foreach.hpp> #include <boost/test/results_collector.hpp> #include <boost/test/detail/unit_test_parameters.hpp> // Boost #include <boost/timer.hpp> // STL #include <algorithm> #include <vector> #include <boost/test/detail/suppress_warnings.hpp> #if BOOST_WORKAROUND(__BORLANDC__, < 0x600) && \ BOOST_WORKAROUND(_STLPORT_VERSION, <= 0x450) \ /**/ using std::rand; // rand is in std and random_shuffle is in _STL #endif //____________________________________________________________________________// namespace boost { namespace unit_test { // ************************************************************************** // // ************** test_unit ************** // // ************************************************************************** // test_unit::test_unit( const_string name, test_unit_type t ) : p_type( t ) , p_type_name( t == tut_case ? "case" : "suite" ) , p_id( INV_TEST_UNIT_ID ) , p_name( std::string( name.begin(), name.size() ) ) { } //____________________________________________________________________________// void test_unit::depends_on( test_unit* tu ) { m_dependencies.push_back( tu->p_id ); } //____________________________________________________________________________// bool test_unit::check_dependencies() const { #if BOOST_WORKAROUND(__SUNPRO_CC, BOOST_TESTED_AT(0x530) ) BOOST_TEST_FOREACH( test_unit_id, tu_id, const_cast<test_unit*>(this)->m_dependencies ) { #else BOOST_TEST_FOREACH( test_unit_id, tu_id, m_dependencies ) { #endif if( !unit_test::results_collector.results( tu_id ).passed() ) return false; } return true; } //____________________________________________________________________________// // ************************************************************************** // // ************** test_case ************** // // ************************************************************************** // test_case::test_case( const_string name, callback0<> const& test_func ) : test_unit( name, (test_unit_type)type ) #if BOOST_WORKAROUND(BOOST_MSVC,<1300) , m_test_func( clone( test_func ) ) #else , m_test_func( test_func ) #endif { // !! weirdest MSVC BUG; try to remove this statement; looks like it eats first token of next statement #if BOOST_WORKAROUND(BOOST_MSVC,<1300) 0; #endif framework::register_test_unit( this ); } #if BOOST_WORKAROUND(BOOST_MSVC,<1300) // Likely due to parsing bugs, MSVC 6.0 necessitates this clone function // for initialization of test_case::m_test_func, as a direct use of new // triggers a spurious error. Also, the extra ; is required to make // the compiler happy. callback0<>* test_case::clone(const callback0<>& test_func) { return new callback0<>( test_func );; } #endif //____________________________________________________________________________// // ************************************************************************** // // ************** test_suite ************** // // ************************************************************************** // //____________________________________________________________________________// test_suite::test_suite( const_string name ) : test_unit( name, (test_unit_type)type ) { framework::register_test_unit( this ); } //____________________________________________________________________________// // !! need to prevent modifing test unit once it is added to tree void test_suite::add( test_unit* tu, counter_t expected_failures, unsigned timeout ) { if( expected_failures != 0 ) tu->p_expected_failures.value = expected_failures; p_expected_failures.value += tu->p_expected_failures; if( timeout != 0 ) tu->p_timeout.value = timeout; m_members.push_back( tu->p_id ); tu->p_parent_id.value = p_id; } //____________________________________________________________________________// void test_suite::add( test_unit_generator const& gen, unsigned timeout ) { test_unit* tu; while((tu = gen.next(), tu)) add( tu, 0, timeout ); } //____________________________________________________________________________// // ************************************************************************** // // ************** traverse_test_tree ************** // // ************************************************************************** // void traverse_test_tree( test_case const& tc, test_tree_visitor& V ) { V.visit( tc ); } //____________________________________________________________________________// void traverse_test_tree( test_suite const& suite, test_tree_visitor& V ) { if( !V.test_suite_start( suite ) ) return; try { if( runtime_config::random_seed() == 0 ) { BOOST_TEST_FOREACH( test_unit_id, id, suite.m_members ) traverse_test_tree( id, V ); } else { std::vector<test_unit_id> members( suite.m_members ); std::random_shuffle( members.begin(), members.end() ); BOOST_TEST_FOREACH( test_unit_id, id, members ) traverse_test_tree( id, V ); } } catch( test_being_aborted const& ) { V.test_suite_finish( suite ); framework::test_unit_aborted( suite ); throw; } V.test_suite_finish( suite ); } //____________________________________________________________________________// void traverse_test_tree( test_unit_id id, test_tree_visitor& V ) { if( test_id_2_unit_type( id ) == tut_case ) traverse_test_tree( framework::get<test_case>( id ), V ); else traverse_test_tree( framework::get<test_suite>( id ), V ); } //____________________________________________________________________________// // ************************************************************************** // // ************** object generators ************** // // ************************************************************************** // namespace ut_detail { std::string normalize_test_case_name( const_string name ) { return ( name[0] == '&' ? std::string( name.begin()+1, name.size()-1 ) : std::string( name.begin(), name.size() ) ); } //____________________________________________________________________________// } // namespace ut_detail } // namespace unit_test } // namespace boost //____________________________________________________________________________// #include <boost/test/detail/enable_warnings.hpp> // *************************************************************************** // Revision History : // // $Log: unit_test_suite.ipp,v $ // Revision 1.13 2006/02/23 15:33:15 rogeeff // workaround restored // // Revision 1.12 2006/01/28 08:53:57 rogeeff // VC6.0 workaround removed // // Revision 1.11 2005/12/14 05:54:41 rogeeff // *** empty log message *** // // Revision 1.10 2005/04/18 04:55:36 rogeeff // test unit name made read/write // // Revision 1.9 2005/03/23 21:02:25 rogeeff // Sunpro CC 5.3 fixes // // Revision 1.8 2005/03/21 15:33:15 rogeeff // check reworked // // Revision 1.7 2005/02/25 21:27:44 turkanis // fix for random_shuffle on Borland 5.x w/ STLPort // // Revision 1.6 2005/02/21 10:12:24 rogeeff // Support for random order of test cases implemented // // Revision 1.5 2005/02/20 08:27:07 rogeeff // This a major update for Boost.Test framework. See release docs for complete list of fixes/updates // // *************************************************************************** #endif // BOOST_TEST_UNIT_TEST_SUITE_IPP_012205GER
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:45C18FD7.1030301@chello.at...
Gennadiy Rozental wrote:
Boost.Test doesn't support DLLs for msvc 6.5. And have no plans for this to change.
So what? Some of the test tests are explicitly making use of DLL's. Should these simply omitted for msvc-6.5? Shall I try to modify the Jamfile?
These should be marked as expected failures and happily ignored. Boost.Test supports this compiler only up to the level required by the boost regression tests. No libraries were using DLL version of Boost.Test with this compiler before 1.34 and accordingly couldn't expect it to start working. I've looked on the workaround proposed. It looks more like a hack. * You need to switch from object of class that contains shared_ptr on shared_ptr to this class - extra level of indirection * You need to add clone methods to workaround bug with explicit new * You need to add extra level of indication to convert from object to pointer * You need to add dummy semicolon, just to satisfy this compiler And all that essentially for nothing - Boost.Test do not intend to support DLL build for this compiler. I'd rather keep the code clean. Gennadiy
Gennadiy Rozental wrote:
These should be marked as expected failures and happily ignored. Boost.Test supports this compiler only up to the level required by the boost regression tests. No libraries were using DLL version of Boost.Test with this compiler before 1.34 and accordingly couldn't expect it to start working.
I've looked on the workaround proposed. It looks more like a hack. * You need to switch from object of class that contains shared_ptr on shared_ptr to this class - extra level of indirection * You need to add clone methods to workaround bug with explicit new * You need to add extra level of indication to convert from object to pointer * You need to add dummy semicolon, just to satisfy this compiler
And all that essentially for nothing - Boost.Test do not intend to support DLL build for this compiler. I'd rather keep the code clean.
Thank you for clarification. There is yet another one. Could you please also comment on its severity? compile-c-c++ ..\..\..\bin.v2\libs\test\test\test_fp_comparisons.test\msvc-6.5\debug\threading-multi\test_fp_comparisons.obj test_fp_comparisons.cpp ..\..\..\boost/test/unit_test_log.hpp(91) : warning C4275: non dll-interface class 'boost::unit_test::singleton<class boost::unit_test::unit_test_log_t>' used as base for dll-interface class 'boost::unit_test::unit_test_log_t' ..\..\..\boost/test/unit_test_log.hpp(91) : see declaration of 'unit_test_log_t' test_fp_comparisons.cpp(141) : error C2780: 'class boost::_bi::bind_t<R,class boost::_mfi::dm<R,T>,class boost::_bi::list1<class boost::_bi::value<R> > > __cdecl boost::bind(R T::*,A1)' : expects 2 arguments - 3 provided ..\..\..\boost/bind.hpp(1554) : see declaration of 'bind' test_fp_comparisons.cpp(141) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8) const,A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 3 provided ..\..\..\boost/bind/bind_mf_cc.hpp(222) : see declaration of 'bind' .... Lot of similar following. Obviously this does not currently effect any of the other regressions on msvc-6.5. Will you mark them as expected failures, or shall I do it? one final question though: Given that we mark a lot of tests as unusable, how reliable is the regression of the other libraries? Thank you, Roland
----- Mensaje original ----- De: Roland Schwarz <roland.schwarz@chello.at> Fecha: Jueves, Febrero 1, 2007 9:55 pm Asunto: Re: [boost] boost_unit_test_framework cannot be built asDLLwithmsvc-6.5 Para: boost@lists.boost.org
Gennadiy Rozental wrote:
These should be marked as expected failures and happily ignored. Boost.Test supports this compiler only up to the level required by the boost regression tests. No libraries were using DLL version of Boost.Test with this compiler before 1.34 and accordingly couldn't expect it to start working.
I've looked on the workaround proposed. It looks more like a hack. [...] And all that essentially for nothing - Boost.Test do not intend to support DLL build for this compiler. I'd rather keep the code clean.
Thank you for clarification.
Hello Gennadiy and Roland, I concur the proposed workaround is ugly as sin, and given your maintenance policy regarding MSVC 6.0, it makes perfect sense to refrain from trying to fix the problem. What I wonder is, instead of marking these as expected failures, couldn't we modify the Jamfile.v2 so as to not run any test in DLL mode for this compiler? I know close to zero about B.Bv2, but the Jamfile.v2 used for these tests has a rule called test-btl-lib that, maybe, could be added something like <msvc-6.5>:link<static> to always force static linking. (Hope Volodya or someone knowledgeable about B.Bv2 can validate the syntax.) IMHO forcing static for MSVC 6.5 is much better than simply marking those tests as expected failiures, since the *intrisinc* functionality being tested (boost_check_equal etc.) *does* work for this compiler. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:45C25463.30303@chello.at...
Gennadiy Rozental wrote:
These should be marked as expected failures and happily ignored. Boost.Test supports this compiler only up to the level required by the boost regression tests. No libraries were using DLL version of Boost.Test with this compiler before 1.34 and accordingly couldn't expect it to start working.
I've looked on the workaround proposed. It looks more like a hack. * You need to switch from object of class that contains shared_ptr on shared_ptr to this class - extra level of indirection * You need to add clone methods to workaround bug with explicit new * You need to add extra level of indication to convert from object to pointer * You need to add dummy semicolon, just to satisfy this compiler
And all that essentially for nothing - Boost.Test do not intend to support DLL build for this compiler. I'd rather keep the code clean.
Thank you for clarification.
There is yet another one. Could you please also comment on its severity?
compile-c-c++ ..\..\..\bin.v2\libs\test\test\test_fp_comparisons.test\msvc-6.5\debug\threading-multi\test_fp_comparisons.obj
Any failures on msvc 6.5 are expected ;). I don't test against this compiler anymore and have no way of ensuring that my own unit test pass it. And that's beside the point that even only critical issues affecting boost regression testing are going to be fixed. Gennadiy
Gennadiy Rozental wrote:
Any failures on msvc 6.5 are expected ;). I don't test against this compiler anymore and have no way of ensuring that my own unit test pass it. And that's beside the point that even only critical issues affecting boost regression testing are going to be fixed.
Unfortunately this seems to collide with the agreement, that 1.34 is the last official release that will support the msvc-6.5 compiler. Another try to reach a compromise: You termed the patch to work around the embedded callback "a ugly hack" and want to keep the code-base clean. Ok, I can understand this very well, and wouldn't object. But we could apply this patch _only_ in the RC_1_34_0 branch, make msvc-6.5 happy _and_ keep the test code base clean for further development. Would you also object against this? Thank you for your patience. Roland Btw.: I would be interested what Thomas Witt has to say about the issue.
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:45C48571.5060602@chello.at...
Gennadiy Rozental wrote:
Any failures on msvc 6.5 are expected ;). I don't test against this compiler anymore and have no way of ensuring that my own unit test pass it. And that's beside the point that even only critical issues affecting boost regression testing are going to be fixed.
Unfortunately this seems to collide with the agreement, that 1.34 is the last official release that will support the msvc-6.5 compiler.
No. It does not. In general question of particular platform support is library developer/maintainer decision. I promissed msvc 6.5 support in 1.34 for all features that were available in 1.33.1 including and specifically concentrating on all the features used by boost unit tests. No support for new features is expected. Gennadiy
Hi, Gennadiy Rozental wrote:
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message
Unfortunately this seems to collide with the agreement, that 1.34 is the last official release that will support the msvc-6.5 compiler.
No. It does not. In general question of particular platform support is library developer/maintainer decision. I promissed msvc 6.5 support in 1.34 for all features that were available in 1.33.1 including and specifically concentrating on all the features used by boost unit tests. No support for new features is expected.
FWIW Gennadiy is right here with respect to the agreed upon serialization support in 1.34.0. Thanks Gennadiy for wrangling with vc6 so that our regression testing is still working. That being said I would certainly appreciate small low risk changes that solve regression/functionality problems in other libraries with vc6. AFAICS this can provide great value at little cost. Whether the proposed change is in that category is not for me to tell. Thomas -- Thomas Witt witt@acm.org
"Thomas Witt" <witt@acm.org> wrote in message news:eq8qe0$u9u$1@sea.gmane.org...
Hi,
Gennadiy Rozental wrote:
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message
Unfortunately this seems to collide with the agreement, that 1.34 is the last official release that will support the msvc-6.5 compiler.
No. It does not. In general question of particular platform support is library developer/maintainer decision. I promissed msvc 6.5 support in 1.34 for all features that were available in 1.33.1 including and specifically concentrating on all the features used by boost unit tests. No support for new features is expected.
FWIW Gennadiy is right here with respect to the agreed upon serialization support in 1.34.0. Thanks Gennadiy for wrangling with vc6 so that our regression testing is still working. That being said I would certainly appreciate small low risk changes that solve regression/functionality problems in other libraries with vc6. AFAICS
From what I know, the patch is trying to address errors in Boost.Test own unit tests, which I don't really care to fix for this compiler.
Gennadiy Rozental wrote:
"Thomas Witt" <witt@acm.org> wrote in message news:eq8qe0$u9u$1@sea.gmane.org...
From what I know, the patch is trying to address errors in Boost.Test own unit tests, which I don't really care to fix for this compiler.
In that case why don't you mark the test as expected fail for vc6? Thanks Thomas -- Thomas Witt witt@acm.org
"Thomas Witt" <witt@acm.org> wrote in message news:eqee60$n9r$1@sea.gmane.org...
Gennadiy Rozental wrote:
"Thomas Witt" <witt@acm.org> wrote in message news:eq8qe0$u9u$1@sea.gmane.org...
From what I know, the patch is trying to address errors in Boost.Test own unit tests, which I don't really care to fix for this compiler.
In that case why don't you mark the test as expected fail for vc6?
I don't have any objections. I am a little busy at the moment to do it myself. Could someone with cvs access deal with it. Gennadiy
Gennadiy Rozental wrote:
These should be marked as expected failures and happily ignored.
Do you have any objections to apply the attached patch to libs/test/test/Jamfile.v2 and only mark the remaining tests as expected to fail? Regards Roland Index: Jamfile.v2 =================================================================== RCS file: /cvsroot/boost/boost/libs/test/test/Jamfile.v2,v retrieving revision 1.9.2.2 diff -u -r1.9.2.2 Jamfile.v2 --- Jamfile.v2 30 Nov 2006 10:30:09 -0000 1.9.2.2 +++ Jamfile.v2 1 Feb 2007 23:44:04 -0000 @@ -15,6 +15,7 @@ : $(pattern_file) : #<stlport-iostream>on <toolset>borland:<cxxflags>-w-8080 + <toolset>msvc-6.5:<link>static <define>BOOST_TEST_NO_AUTO_LINK=1 # requirements : $(test-name) ] ;
Roland Schwarz wrote:
Gennadiy Rozental wrote:
These should be marked as expected failures and happily ignored.
Do you have any objections to apply the attached patch to libs/test/test/Jamfile.v2 and only mark the remaining tests as expected to fail?
I think if Boost.Test cannot be built as DLL on msvc-6.5, then: <toolset>msvc-6.5:<link>static should go to libs/test/build/Jamfile.v2, not the test Jamfile, thereby disabling shared libraries of Boost.Test on that compiler completely. Gennadiy, would you object to such a change? - Volodya
"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:E1HCt1h-0002pS-K3@zigzag.lvk.cs.msu.su...
Roland Schwarz wrote:
Gennadiy Rozental wrote:
These should be marked as expected failures and happily ignored.
Do you have any objections to apply the attached patch to libs/test/test/Jamfile.v2 and only mark the remaining tests as expected to fail?
I think if Boost.Test cannot be built as DLL on msvc-6.5, then:
<toolset>msvc-6.5:<link>static
should go to libs/test/build/Jamfile.v2, not the test Jamfile, thereby disabling shared libraries of Boost.Test on that compiler completely.
Gennadiy, would you object to such a change?
Let's go ahead and do this Gennadiy
Gennadiy Rozental wrote:
Let's go ahead and do this
Patch applied to RC_1_34_0 Roland ? Jamfile.v2.diff Index: Jamfile.v2 =================================================================== RCS file: /cvsroot/boost/boost/libs/test/build/Jamfile.v2,v retrieving revision 1.10.2.2 diff -u -r1.10.2.2 Jamfile.v2 --- Jamfile.v2 10 Nov 2006 19:59:52 -0000 1.10.2.2 +++ Jamfile.v2 3 Feb 2007 14:12:14 -0000 @@ -68,7 +68,7 @@ lib boost_test_exec_monitor : $(TEST_EXEC_MON_SOURCES).cpp : <link>static ; -lib boost_unit_test_framework : $(UTF_SOURCES).cpp ; +lib boost_unit_test_framework : $(UTF_SOURCES).cpp : <toolset>msvc-6.5:<link>static ; alias minimal : : : :
Gennadiy Rozental wrote:
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:45BE5655.7040102@chello.at...
I am trying to get the regressions straight for msvc-6.5. I discovered, that some of the test's test are failing with msvc-6.5.
I tracked this down to the fact, that the boost_unit_test_framework cannot be built as a DLL.
Boost.Test doesn't support DLLs for msvc 6.5. And have no plans for this to change.
joaquin provided a workaround for some of the problems, as can be seen from his answer within this thread of discussion. I have tried it, and were able to reproduce his found results, i.e. some of the regressions are seemingly fixed. Have you any objections to apply his patch? Roland
participants (6)
-
"JOAQUIN LOPEZ MU?Z" -
Gennadiy Rozental -
Joaquín Mª López Muñoz
-
Roland Schwarz -
Thomas Witt -
Vladimir Prus