Boost test tools using static library - operator new link problem
In release mode (debug to libboost_unit_test_framework-vc80-mt-sgd-1_34.lib is OK, and dll debug and release libs also OK) Compiling... test_tools_test.cpp Linking... libboost_unit_test_framework-vc80-mt-s-1_34.lib(exception_safety.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj) I:\boost-06-01-13-0500\libs\test\build\msvc71_proj\Release\test_tools_test_s tatic.exe : fatal error LNK1169: one or more multiply defined symbols found Suggestions about what I am doing wrong? Thanks Paul PS Trying to avoid transition to monitor defenestration mode ;-) -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
This should be fixed now. Let me know. Gennadiy
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A Bristow | Sent: 23 January 2006 18:59 | To: boost@lists.boost.org | Subject: [boost] Boost test tools using static library - | operator new linkproblem | | In release mode (debug to | libboost_unit_test_framework-vc80-mt-sgd-1_34.lib | is OK, and dll debug and release libs also OK) | | Compiling... | test_tools_test.cpp | Linking... | libboost_unit_test_framework-vc80-mt-s-1_34.lib(exception_safe | ty.obj) : | error LNK2005: "void * __cdecl operator new[](unsigned int)" | (??_U@YAPAXI@Z) | already defined in libcpmt.lib(newaop.obj) | I:\boost-06-01-13-0500\libs\test\build\msvc71_proj\Release\tes | t_tools_test_s | tatic.exe : fatal error LNK1169: one or more multiply defined | symbols found | | Suggestions about what I am doing wrong? | | | Thanks | | Paul Thanks for your note saying you have fixed this. I'll try this out as soon as possible. Meanwhile it works with /FORCE. By The Way, before we get too far into doc updates, is there a really good reason why unit test framework and test tools are separate libraries? They appear to be the same apart from one extra file. Would it not reduce confusion/compile time... to just have ONE library file. I'm still not sure I understand when to use either a test_suite unit_unit_test_suite, or int test_main.
By The Way, before we get too far into doc updates, is there a really good reason why unit test framework and test tools are separate libraries? They
Test Tools isn't a separate library. Just a separate component of Boost.Test.
appear to be the same apart from one extra file. Would it not reduce confusion/compile time... to just have ONE library file.
I'm still not sure I understand when to use either a test_suite unit_unit_test_suite, or int test_main.
You probable means the Unit Test Framework vs. the Test Execution Monitor. The later is just single test cases version if first one. To be completely frank with you I do not see real need for the Test Execution Monitor now. It's just as easy to write BOOST_AUTO_TEST_CASE(test_main). But from historical reason I would keep it for now. Gennadiy
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental | Sent: 30 January 2006 15:49 | To: boost@lists.boost.org | Subject: Re: [boost] Boost test tools using static library - | operatornewlinkproblem | | > By The Way, before we get too far into doc updates, is | there a really good | > reason why unit test framework and test tools are separate | libraries? | > They | | Test Tools isn't a separate library. Just a separate component of | Boost.Test. | | > appear to be the same apart from one extra file. Would it | not reduce | > confusion/compile time... to just have ONE library file. | > | > I'm still not sure I understand when to use either a test_suite | > unit_unit_test_suite, or int test_main. | | You probable means the Unit Test Framework vs. the Test | Execution Monitor. | The later is just single test cases version if first one. To | be completely | frank with you I do not see real need for the Test Execution | Monitor now. | It's just as easy to write BOOST_AUTO_TEST_CASE(test_main). But from | historical reason I would keep it for now. I think you should think about at least deprecating it, and taking it out of the new documentation (relegating it to a 'historial' annex out of the main product description). I think it seriously confuses the whole business. When I started, I almost tripped at the first hurdle because I didn't know what I wanted. I fear others won't have been sold by your excellent 'Today I'm going to start testing as I write, flossing my teeth ..." article. There is also additional confusion with minimal test. Is it now looking so simple that we don't need that (documented) either? Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
I think it seriously confuses the whole business. When I started, I almost tripped at the first hurdle because I didn't know what I wanted. I fear others won't have been sold by your excellent 'Today I'm going to start testing as I write, flossing my teeth ..." article.
There is also additional confusion with minimal test. Is it now looking so simple that we don't need that (documented) either?
I personally agree with you. Minimal facility is more light weight. Some people value this. Lets hear from the community. Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:drrm1b$50q$1@sea.gmane.org...
I think it seriously confuses the whole business. When I started, I almost tripped at the first hurdle because I didn't know what I wanted. I fear others won't have been sold by your excellent 'Today I'm going to start testing as I write, flossing my teeth ..." article.
There is also additional confusion with minimal test. Is it now looking so simple that we don't need that (documented) either?
I personally agree with you. Minimal facility is more light weight. Some people value this. Lets hear from the community.
FWIW I would like to use Minimal Test but unfortunately it doesnt define BOOST_CHECK_CLOSE so I wound up faking all the test macros I needed myself. I had to do something because Bjam wouldnt build anything boost using DJGPP gcc on Windows, so I couldnt build test for that compiler, easily at least. regards Andy Little
On Mon, 30 Jan 2006 17:43:51 -0000 "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:
I think it seriously confuses the whole business. When I started, I almost tripped at the first hurdle because I didn't know what I wanted. I fear others won't have been sold by your excellent 'Today I'm going to start testing as I write, flossing my teeth ..." article.
What article is that???
Well it was Gennadiy's original 'selling unit testing' article. I can't now find it - on the machine before last :-(( Can the author produce a copy? Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Jody Hagins | Sent: 02 February 2006 13:50 | To: boost@lists.boost.org | Subject: Re: [boost] Boost test tools - do we still need test | tools and minimal test? | | > I think it seriously confuses the whole business. When I started, I | > almost tripped at the first hurdle because I didn't know what I | > wanted. I fear others won't have been sold by your excellent 'Today | > I'm going to start testing as I write, flossing my teeth | ..." article. | | | What article is that???
participants (4)
-
Andy Little -
Gennadiy Rozental -
Jody Hagins -
Paul A Bristow