I attempted to use the minimal verision of boost test. In order to do this I replaced occurencs of #include <boost/test/exec_monitor.hpp> with #include <boost/test/minimal.hpp> This generates a few problems. a) In the tests which use the serialization DLL, It seems that references are being made to symbols in the library. Here is the output from the link. I can't figure out why this is. test_array.cpp C:\BoostHead\boost\test\impl\execution_monitor.ipp(204) : warning C4273: 'boost::execution_monitor::execute' : inconsistent dll linkage C:\BoostHead\boost\test\impl\execution_monitor.ipp(496) : warning C4273: 'boost::execution_monitor::catch_signals' : inconsistent dll linkage C:\BoostHead\boost\test\impl\execution_monitor.ipp(624) : warning C4273: 'boost::detect_memory_leaks' : inconsistent dll linkage C:\BoostHead\boost\test\impl\execution_monitor.ipp(646) : warning C4273: 'boost::break_memory_alloc' : inconsistent dll linkage Linking to lib file: boost_serialization-vc71-mt-gd-1_34.lib Linking to lib file: boost_serialization-vc71-mt-gd-1_34.lib Linker output: Creating library c:\BoostHead\bin\boost\libs\serialization\test\test_array_binary_archive_dll.test\vc-7_1\debug\threading-multi\test_array_binary_archive_dll.lib and object c:\BoostHead\bin\boost\libs\serialization\test\test_array_binary_archive_dll.test\vc-7_1\debug\threading-multi\test_array_binary_archive_dll.exp test_array.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::execution_exception::execution_exception(enum boost::execution_exception::error_code,class boost::unit_test::basic_cstring<char const >)" (__imp_??0execution_exception@boost@@QAE@W4error_code@01@V?$basic_cstring@$$CBD@unit_test@1@@Z) referenced in function "void __cdecl boost::detail::report_error(enum boost::execution_exception::error_code,class boost::unit_test::basic_cstring<char const >,class boost::unit_test::basic_cstring<char const >)" (?report_error@detail@boost@@YAXW4error_code@execution_exception@2@V?$basic_cstring@$$CBD@unit_test@2@1@Z) test_array.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class boost::unit_test::basic_cstring<char const > __thiscall boost::execution_exception::what(void)const " (__imp_?what@execution_exception@boost@@QBE?AV?$basic_cstring@$$CBD@unit_test@2@XZ) referenced in function $L159233 test_array.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: enum boost::execution_exception::error_code __thiscall boost::execution_exception::code(void)const " (__imp_?code@execution_exception@boost@@QBE?AW4error_code@12@XZ) referenced in function $L159233 test_array.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::execution_monitor::~execution_monitor(void)" (__imp_??1execution_monitor@boost@@QAE@XZ) referenced in function _main test_array.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::execution_monitor::execution_monitor(void)" (__imp_??0execution_monitor@boost@@QAE@XZ) referenced in function _main c:\BoostHead\bin\boost\libs\serialization\test\test_array_binary_archive_dll.test\vc-7_1\debug\threading-multi\test_array_binary_archive_dll.exe : fatal error LNK1120: 5 unresolved externals b) At least a few "test tools" macros aren't present BOOST_CHECK_EQUAL and BOOST_CHECK_MESSAGE among themRobert Ramey
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e1ndd8$ebp$1@sea.gmane.org...
I attempted to use the minimal verision of boost test. In order to do this I replaced occurencs of
#include <boost/test/exec_monitor.hpp> with #include <boost/test/minimal.hpp>
Is there any particular reasons why you want to do this? My general recommendation: unless there is a reason stick with UTF.
This generates a few problems.
a) In the tests which use the serialization DLL, It seems that references are being made to symbols in the library. Here is the output from the link. I can't figure out why this is.
I don't think you could do this. My guess is that you define BOOST_DYN_LINK that will cause dynamic version of execution monitor sumbols to be compiled. And minimal test facility isn't cut for that.
b) At least a few "test tools" macros aren't present BOOST_CHECK_EQUAL and BOOST_CHECK_MESSAGE among themRobert Ramey
Actually 99% of them is absent. And only 3 are present. But that was your choice, isn't it? Gennadiy
Gennadiy Rozental wrote:
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e1ndd8$ebp$1@sea.gmane.org...
I attempted to use the minimal verision of boost test. In order to do this I replaced occurencs of
#include <boost/test/exec_monitor.hpp> with #include <boost/test/minimal.hpp>
Is there any particular reasons why you want to do this? My general recommendation: unless there is a reason stick with UTF.
My understanding is that UTF will no longer support all the platforms I want to run tests on. It seemed that the minimal testing environment would be sufficient for my purposes so I had hoped that it would support a wider variety of platforms.
This generates a few problems.
a) In the tests which use the serialization DLL, It seems that references are being made to symbols in the library. Here is the output from the link. I can't figure out why this is.
I don't think you could do this. My guess is that you define BOOST_DYN_LINK that will cause dynamic version of execution monitor sumbols to be compiled.
I do define BOOST_DYN_LINK. But I don't think that should trigger auto-linking from exec_monitor or utf library. I had a similar problem in the serialization library whereby simple inclusion of a header triggered auto-link even though functions weren't called - it was an oversight that turned out to be non-trivial to fix.
And minimal test facility isn't cut for that.
So it would seem.
b) At least a few "test tools" macros aren't present BOOST_CHECK_EQUAL and BOOST_CHECK_MESSAGE among themRobert Ramey
Actually 99% of them is absent. And only 3 are present. But that was your choice, isn't it?
My mistake. I misread "In addition it defines several simple test tools that behave similarly to ones defined in Test Tools." to mean it supported tools similar to those defined in Test Tools. As it turns out, it seems I'm only using relatively few of the test tools.
Gennadiy
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e1pqm7$g16$1@sea.gmane.org...
Gennadiy Rozental wrote:
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e1ndd8$ebp$1@sea.gmane.org...
I attempted to use the minimal verision of boost test. In order to do this I replaced occurencs of
#include <boost/test/exec_monitor.hpp> with #include <boost/test/minimal.hpp>
Is there any particular reasons why you want to do this? My general recommendation: unless there is a reason stick with UTF.
My understanding is that UTF will no longer support all the platforms I want to run tests on. It seemed that the minimal testing environment would be sufficient for my purposes so I had hoped that it would support a wider variety of platforms.
UTF will work on all compilers boost runnig regresssion testing on. Do you want to run test for any other configurations?
This generates a few problems.
a) In the tests which use the serialization DLL, It seems that references are being made to symbols in the library. Here is the output from the link. I can't figure out why this is.
I don't think you could do this. My guess is that you define BOOST_DYN_LINK that will cause dynamic version of execution monitor sumbols to be compiled.
I do define BOOST_DYN_LINK. But I don't think that should trigger auto-linking from exec_monitor or utf library. I had a similar problem in
I don't think it has anything to do with autolinking. It just adds dllexport/dllimport grist to the function definition/declaration. Gennadiy
Gennadiy Rozental wrote:
My understanding is that UTF will no longer support all the platforms I want to run tests on. It seemed that the minimal testing environment would be sufficient for my purposes so I had hoped that it would support a wider variety of platforms.
UTF will work on all compilers boost runnig regresssion testing on. Do you want to run test for any other configurations?
yes.
participants (2)
-
Gennadiy Rozental -
Robert Ramey