Re: [boost] Problem linking Boost Unit Test Library on windows(1.33.0)
Hello Martin! First of all thanks for the answer. Martin Schulz <> wrote:
Hello Markus,
you should not link your _application_ against boost test at all. IMHO, you should compile the test cases in a separate executable that runs all tests one after the other.
I had completely wrong information here. Our setup is exactly the one you described. The console app which links against the test framework doesn't link. Our main application links fine though (without the test framework of course)... The error message is (sorry for the german messages... Damn i18n :)): libboost_unit_test_framework.a(unit_test_main.obj) : error LNK2005: _main ist bereits in _check_owerrdialogs.o definiert. libboost_unit_test_framework.a(framework.obj) : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""class boost::unit_test::test_suite * __cdecl init_unit_test_suite(int,char * * const)" (?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z)" in Funktion ""void __cdecl boost::unit_test::framework::init(int,char * * const)" (?init@framework@unit_test@boost@@YAXHQAPAD@Z)". wamas-test_global_checkowerrdialogs__check_owerrdialogs.exe : fatal error LNK1120: 1 nicht aufgelöste externe Verweise. Basically it says, there is allready a main in the test framework, and that there is no init_unit_test_suite which it would require.
The simplest way to avoid any link hassle there is to have a single cpp file containing
#define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> #include <boost/test/included/unit_test_framework.hpp>
I looked into the test program he is trying to link. It has a main() which does some initialization, and the adds some test cases. Should this be changed to be a init_unit_test_suite instead of main? If yes, does this work on all platforms, or is this just a windows thing? Also i cannot find BOOST_AUTO_TEST_MAIN anywhere in the source, and boost/test/unit_test.hpp is included instead of auto_unit_test.hpp. unit_test_framework.hpp is also not included... Cheers, Markus
And compile this (together with your test cases) into a command line executable. That way, the linker has a little bit more to do on each compiler run, but you do avoid any mismatch of compiler options and the like.
Yours,
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Duft Markus Sent: Donnerstag, 28. Februar 2008 08:42 To: boost@lists.boost.org Subject: [boost] Problem linking Boost Unit Test Library on windows (1.33.0)
Hi!
I have a problem linking our application on windows. Somebody added test cases using the boost unit test library, and since then windows won't link anymore. The problem is, that the boost library contains a "main" and doesn't seem to contain a "init_unit_test_suite" function (am I missing a library?). It works on all other systems, is windows unsupported there?
Is there any more information I should gather for you to see the problem, or is this a known issue (I remember seeing something on the list about this, but I think it was about a newer boost version. Can any eventually made changes be expressed as a patch for 1.33.0 so I can locally fix the issue, and won't need an upgrade)?
Cheers, Markus _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello Markus,
The simplest way to avoid any link hassle there is to have a single cpp file containing
#define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> #include <boost/test/included/unit_test_framework.hpp>
I looked into the test program he is trying to link. It has a main() which does some initialization, and the adds some test cases. Should this be changed to be a init_unit_test_suite instead of main? If yes, does this work on all platforms, or is this just a windows thing?
For me "boost::unit_test::test_suite* init_unit_test_suite( int argc, char* argv[] )" instead of "int main( int argc, char* argv[] )" works on all platforms, but I'm using boost 1.34.1, so I can't tell whether this is also true for boost 1.33.0. I have a globally defined "BOOST_TEST_INCLUDED" (in the same way that "NDEBUG" is globally defined) instead of the local "#define BOOST_AUTO_TEST_MAIN", but this may also be related to boost 1.34.1.
Also i cannot find BOOST_AUTO_TEST_MAIN anywhere in the source, and boost/test/unit_test.hpp is included instead of auto_unit_test.hpp. unit_test_framework.hpp is also not included...
strange, for boost 1.33.0, it is used in "boost/test/auto_unit_test.hpp" (line 211), while for boost 1.34.1, it is used in "boost/test/detail/config.hpp" (line 98). I think I can remember that both the globally defined "BOOST_TEST_INCLUDED" and the locally defined "#define BOOST_AUTO_TEST_MAIN" are "lazy" solutions that are not recommended. Still, they are simply convenient and probably the simplest way to make boost/test work. Regards, Thomas
Thomas Klimpel <Thomas.Klimpel <at> synopsys.com> writes:
I have a globally defined "BOOST_TEST_INCLUDED" (in the same way that "NDEBUG" is globally defined) instead of the local "#define BOOST_AUTO_TEST_MAIN", but this may also be related to boost 1.34.1.
You are doing something fidhy here. This is internal Boost.Test macro and users are not expected to define it. Gennadiy
I have a globally defined "BOOST_TEST_INCLUDED" (in the same way that "NDEBUG" is globally defined) instead of the local "#define BOOST_AUTO_TEST_MAIN", but
Dear Gennadiy, Gennadiy Rozental writes: this
may also be related to boost 1.34.1.
You are doing something fidhy here. This is internal Boost.Test macro and users are not expected to define it.
When I upgraded from boost 1.33.0 to boost 1.34.1, I got link errors on Windows. I tried it with the documentation from http://www.boost.org/libs/test/doc/components/utf/compilation.html and with your recent suggestions, but I haven't found another way to remove the linking errors than to globally define "BOOST_TEST_INCLUDED" (or link against boost_unit_test_framework-XXX.dll, but I prefered using "included" option). Maybe I haven't tried hard enough, but I have also other things to do than try to exactly follow an incomplete documentation. I admit that with boost 1.33.0, simply following the documentation worked just fine, so Markus Duft is probably not forced to use my "fidhy" solution.
New docs here:
parmedia.net/~rogeeff/html/index.html
explain how each variant works.
I tried the link, but it doesn't work for me. Regards, Thomas
and with your recent suggestions, but I haven't found another way to remove the linking errors than to globally define "BOOST_TEST_INCLUDED" (or link against boost_unit_test_framework-XXX.dll, but I prefered using "included" option). Maybe I haven't tried hard enough, but I have also other things to do than try to exactly follow an incomplete documentation.
I have done a search for "BOOST_TEST_INCLUDED" in the boost/test sources now, and came to the conclusion, that globally defining "BOOST_TEST_NO_LIB" will have a similar effect. I tried this, and it works. Is this the "officially supported" solution? But how am I supposed to know from the sources that globally defining "BOOST_TEST_NO_LIB" is the expected way to do it, while defining "BOOST_TEST_INCLUDED" is "fidhy"? Or is globally defining "BOOST_TEST_NO_LIB" just as "fidhy" as globally defining "BOOST_TEST_INCLUDED"?
Thomas Klimpel <Thomas.Klimpel <at> synopsys.com> writes:
and with your recent suggestions, but I haven't found another way to remove the linking errors than to globally define "BOOST_TEST_INCLUDED" (or link against boost_unit_test_framework-XXX.dll, but I prefered using "included" option). Maybe I haven't tried hard enough, but I have also other things to do than try to exactly follow an incomplete documentation.
I have done a search for "BOOST_TEST_INCLUDED" in the boost/test sources now, and came to the conclusion, that globally defining "BOOST_TEST_NO_LIB" will have a similar effect. I tried this, and it works.
BOOST_TEST_NO_LIB is used to prevent auto-linking and in general has nothing to do with the problem you expirience.
Is this the "officially supported" solution? But how am I supposed to know from the sources that globally defining "BOOST_TEST_NO_LIB" is the expected way to do it, while defining "BOOST_TEST_INCLUDED" is "fidhy"?
Try reading new docs or post an example that fails to link here and I will show a right way.
Or is globally defining "BOOST_TEST_NO_LIB" just as "fidhy" as globally defining "BOOST_TEST_INCLUDED"?
I am not why your sarcasm is warranted here. I am just trying to help. Gennadiy
Hello Gennadiy, thanks for your quick response.
BOOST_TEST_NO_LIB is used to prevent auto-linking and in general has nothing to do with the problem you expirience.
My link problems where auto-linking problems, so they have something to do with BOOST_TEST_NO_LIB. (I know that Markus Duft had other Problems, but all I did was describe him my "setup", because it 'works for me', so I ventured that it might also work for him.)
Is this the "officially supported" solution? But how am I supposed to know from the sources that globally defining "BOOST_TEST_NO_LIB" is the expected way to do it, while defining "BOOST_TEST_INCLUDED" is "fidhy"?
Try reading new docs or post an example that fails to link here and I will show a right way.
The new docs are nice (and I have an idea now how to avoid my problem), but I will first describe my example that fails: I have multiple source files. The file where the function "init_unit_test_suite" is defined contains the line #include <boost/test/included/unit_test.hpp> while all other files contain the line #include <boost/test/unit_test.hpp> Because "boost/test/unit_test.hpp" contains a line that will use the auto-linking feature if #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_TEST_NO_LIB) && \ !defined(BOOST_TEST_SOURCE) && !defined(BOOST_TEST_INCLUDED) I thought that I have to define at least one of these 4 macros, if I want to avoid auto-linking problems. I initially thought that defining BOOST_TEST_INCLUDED is the "officially supported" solution, since my scenario is 'Using "included" option'. My next guess was that defining BOOST_TEST_NO_LIB is the "officially supported" solution. Now you tell me that globally defining any macro at all is already a mistake, so I guess I'm not allowed to include "unit_test.hpp" in more than one source file, and should replace #include <boost/test/unit_test.hpp> by #include <boost/test/test_tools.hpp> #include <boost/test/unit_test_suite.hpp> Correct?
Or is globally defining "BOOST_TEST_NO_LIB" just as "fidhy" as globally defining "BOOST_TEST_INCLUDED"?
I am not why your sarcasm is warranted here. I am just trying to help.
Sorry for the sarcasm. I was a bit annoyed by the typo in the link to the new documentation. I'm really happy with boost/test, because it allows me to concentrate on my unit-tests without bothering to much with the unit-test framework. I used cppunit before, but switched to boost/test, because it was both simpler to use and more powerful (well designed messages for test failures, memory leak detection, easy integration into tool chains, ...). When upgrading to boost 1.34.1, I had to figure out how to make my unit-tests link again on windows. Making them link again was quite easy, but I would have preferred to know the "officially supported" solution, because upgrading to boost 1.35 might otherwise again break something. Regards, Thomas
Thomas Klimpel <Thomas.Klimpel <at> synopsys.com> writes:
When I upgraded from boost 1.33.0 to boost 1.34.1, I got link errors on Windows. I tried it with the documentation from
http://www.boost.org/libs/test/doc/components/utf/compilation.html
1.34.1 docs are indded crippled.
New docs here:
parmedia.net/~rogeeff/html/index.html
explain how each variant works.
I tried the link, but it doesn't work for me.
Sorry, typo. http://patmedia.net/~rogeeff/html/index.html Gennadiy
Duft Markus <Markus.Duft <at> salomon.at> writes:
I looked into the test program he is trying to link. It has a main() which does some initialization, and the adds some test cases. Should this be changed to be a init_unit_test_suite instead of main? If yes, does this work on all platforms, or is this just a windows thing?
You original test was build for Linux and linked with shared library version of Boost.Test. You can continue using this setup if you prefer. Or you can switch to static library. Or single header variant of Boost.Test. New docs here: parmedia.net/~rogeeff/html/index.html explain how each variant works. Gennadiy
participants (3)
-
Duft Markus -
Gennadiy Rozental -
Thomas Klimpel