Multiple link definitions on Darwin tests
Recently, many of the Darwin tests started failing. A bunch of them were the new serialization tests, and I've been working with Robert Ramey to figure out why and fix them. However, I have come to realize that a lot of the failing tests are not in the serialization library. Before I start debugging this myself, does anyone have any suggestions? For example, _all_ the program options tests are failing, with messages like: <http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#program_options-cmdline_test-darwin>
program_options - cmdline_test - darwin
Linker output:
ld: warning table of contents of library: ../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a not sorted slower link editing will result (use the ranlib(1) -s option) ld: multiple definitions of symbol _ZN5boost9unit_test110_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail11xml_printer13print_escapedERSoNS0_13basic_cstringIKcEEE9char_type22first_failed_assertionEv.eh ../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(unit_test_log.o) definition of absolute _ZN5boost9unit_test110_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail11xml_printer13print_escapedERSoNS0_13basic_cstringIKcEEE9char_type22first_failed_assertionEv.eh (value 0x0) ../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(supplied_log_formatters.o) definition of absolute _ZN5boost9unit_test110_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail11xml_printer13print_escapedERSoNS0_13basic_cstringIKcEEE9char_type22first_failed_assertionEv.eh (value 0x0) ld: multiple definitions of symbol boost::unit_test::(anonymous namespace)::first_failed_assertion() ../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(unit_test_log.o) definition of boost::unit_test::(anonymous namespace)::first_failed_assertion() in section (__TEXT,__text) ../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(supplied_log_formatters.o) definition of boost::unit_test::(anonymous namespace)::first_failed_assertion() in section (__TEXT,__text) ld: warning table of contents of library: ../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a not sorted slower link editing will result (use the ranlib(1) -s option)
export DYLD_LIBRARY_PATH c++ -g -o "../bin/boost/libs/program_options/test/cmdline_test.test/darwin/debug/cmdline_test" "../bin/boost/libs/program_options/test/cmdline_test.test/darwin/debug/cmdline_test.o" \ \
-L"../bin/boost/libs/program_options/build/libboost_program_options.a/darwin/debug" -L"../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug" "../bin/boost/libs/program_options/build/libboost_program_options.a/darwin/debug/libboost_program_options-d-1_31.a" "../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a" "../bin/boost/libs/program_options/build/libboost_program_options.a/darwin/debug/libboost_program_options-d-1_31.a" "../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a" \
-- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Hi Marshall,
Before I start debugging this myself, does anyone have any suggestions?
For example, _all_ the program options tests are failing, with messages like: <http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#program_ options-cmdline_test-darwin>
The picture is clear. Boost.Test contains two sources: unit_test_log.cpp and supplied_log_formatters.cpp. Both include detail/supplied_log_formatters.hpp which includes test/xml_printer.hpp. The latter contains a class with a static method, defined in-class. Stictly speaking, that method should be implicitly inline, so linker's error is invalid. However, maybe you could try adding explicit "inline" there and see if some errors go away? <RANT> I really, really don't understand why it's necessary to commit new staff at this point of release process. The file in question, boost/test/detail/xml_printer.hpp was added 2004-07-19, which is *yesterday*. Was there any pressing need for that? Should not Boost.Test be in complete feature freeze for a month already?! Of all Boost.Test functionality I use only 'test_main' and BOOST_CHECK, and I'd be really gratefull if that subset just worked. Just mine opinion, of course. </RANT> - Volodya
Vladimir Prus wrote:
Of all Boost.Test functionality I use only 'test_main' and BOOST_CHECK, and I'd be really gratefull if that subset just worked.
#include <boost/detail/lightweight_test.hpp> int main() { int x = 0; BOOST_TEST( ++x == 1 ); BOOST_TEST( ++x == 1 ); return boost::report_errors(); }
Peter Dimov wrote:
Vladimir Prus wrote:
Of all Boost.Test functionality I use only 'test_main' and BOOST_CHECK, and I'd be really gratefull if that subset just worked.
#include <boost/detail/lightweight_test.hpp>
int main() { int x = 0;
BOOST_TEST( ++x == 1 ); BOOST_TEST( ++x == 1 );
return boost::report_errors(); }
Thank you Peter. After the release, I'll definitely move Spirit to use this simple, no frills, test utility. The requirements for such a facility should be 1) Works 100% on *ALL* compilers 2) Is transparent and does not get in the way (you can pretend it's not there at all) 3) Is 100% stable (no frequent API changes) 4) Is as simple as possible (less chance for Murphy's law to kick in). IMO, Boost.Test does not satisfactorily satisfy these requirements. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Wed, 21 Jul 2004 09:59:58 +0800, Joel de Guzman wrote
Thank you Peter. After the release, I'll definitely move Spirit to use this simple, no frills, test utility. The requirements for such a facility should be 1) Works 100% on *ALL* compilers 2) Is transparent and does not get in the way (you can pretend it's not there at all) 3) Is 100% stable (no frequent API changes) 4) Is as simple as possible (less chance for Murphy's law to kick in). IMO, Boost.Test does not satisfactorily satisfy these requirements.
I have an alternative in date_time: http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/date_time/testfrmwk.... No macros in this one. Code hasn't been modified since well before Boost.Test was invented. Trivially simple usage: date d1(1900,1,1); //1st parameter gets passed to Pass / Fail output //second is condition to check check("1900-01-01 day is 01", d1.day() == 1); //... return printTestStats(); //returns number of failures and prints pass fail Output looks like: ====== BEGIN OUTPUT ====== Pass :: 1900-01-01 day is 01 Pass :: 1900-01-01 month is 01 Pass :: 1900-01-01 year is 1900 ... Pass :: check day of year number 75 Tests Executed: All Succeeded ====== END OUTPUT ====== Jeff ps: I wrote this in anger one day after trying to figure out cppunit -- took me way less time to write this -- never did figure out out how to use cppunit.
Joel de Guzman wrote:
#include <boost/detail/lightweight_test.hpp>
int main() { int x = 0;
BOOST_TEST( ++x == 1 ); BOOST_TEST( ++x == 1 );
return boost::report_errors(); }
Thank you Peter. After the release, I'll definitely move Spirit to use this simple, no frills, test utility.
Hey, I'm thinking about this too. Well, I'd still have to roll my own BOOST_COMPARE_COLLECTIONS, but that's the only extra thing I'd need. - Volodya
Vladimir Prus wrote:
<RANT>
I really, really don't understand why it's necessary to commit new staff at this point of release process. The file in question, boost/test/detail/xml_printer.hpp was added 2004-07-19, which is *yesterday*. Was there any pressing need for that? Should not Boost.Test be in complete feature freeze for a month already?!
Of all Boost.Test functionality I use only 'test_main' and BOOST_CHECK, and I'd be really gratefull if that subset just worked. Just mine opinion, of course.
Not only yours. A change to Boost.Test basically means all tests will have to be recompiled on the testing machines. This means test results will be available at a lower frequency. A higher frequency is very desirable during the release preparations.
</RANT>
Regards, m
Martin Wille wrote:
Vladimir Prus wrote:
<RANT>
I really, really don't understand why it's necessary to commit new staff at this point of release process. The file in question, boost/test/detail/xml_printer.hpp was added 2004-07-19, which is *yesterday*. Was there any pressing need for that? Should not Boost.Test be in complete feature freeze for a month already?!
Of all Boost.Test functionality I use only 'test_main' and BOOST_CHECK, and I'd be really gratefull if that subset just worked. Just mine opinion, of course.
Not only yours. A change to Boost.Test basically means all tests will have to be recompiled on the testing machines. This means test results will be available at a lower frequency. A higher frequency is very desirable during the release preparations.
I'm seriously considering not using Boost.Test in the next Spirit release. IMO, it's more trouble than it's worth. It's not stable. All we basically use is some form of assert. I do not think the fancy stuff are needed at all. If you want stability, use the plain old ASSERT. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
The picture is clear. Boost.Test contains two sources: unit_test_log.cpp and supplied_log_formatters.cpp. Both include detail/supplied_log_formatters.hpp which includes test/xml_printer.hpp. The latter contains a class with a static method, defined in-class.
Stictly speaking, that method should be implicitly inline, so linker's error is invalid. However, maybe you could try adding explicit "inline" there and see if some errors go away?
Could somebody chekc that this would help?
<RANT>
I really, really don't understand why it's necessary to commit new staff at this point of release process. The file in question,
It was pretty innocent fix for Boost.Test XML generation issue. It should work everywhere (and it does for all Windows compilers I have an access to). New file is only to share common code between two files. Gennadiy.
Gennadiy Rozental wrote:
I really, really don't understand why it's necessary to commit new staff
at
this point of release process. The file in question,
It was pretty innocent fix for Boost.Test XML generation issue. It should work everywhere (and it does for all Windows compilers I have an access to). New file is only to share common code between two files.
Sure, it seems pretty innocent. But it broke Darwin. I think there should be no changes in Boost.Test other than simple local textual tweaks (with BOOST_WORKAROUND, probably) at this point of time. It took me maybe two weeks just to get access to environment variables working (including on Darwin), so I no longer believe innocent changes exist. - Volodya
Vladimir Prus wrote:
Gennadiy Rozental wrote:
I really, really don't understand why it's necessary to commit new staff
at
this point of release process. The file in question,
It was pretty innocent fix for Boost.Test XML generation issue. It should work everywhere (and it does for all Windows compilers I have an access to). New file is only to share common code between two files.
Sure, it seems pretty innocent. But it broke Darwin. I think there should be no changes in Boost.Test other than simple local textual tweaks (with BOOST_WORKAROUND, probably) at this point of time.
It took me maybe two weeks just to get access to environment variables working (including on Darwin), so I no longer believe innocent changes exist.
There's no such thing as an innocent fix. More than anyone else, boost developers should know that. I remember before 1.31's release cycle when someone added a whole chunk of "innocent" comments in the code which broke the build (guess how that happened). -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (7)
-
Gennadiy Rozental -
Jeff Garland -
Joel de Guzman -
Marshall Clow -
Martin Wille -
Peter Dimov -
Vladimir Prus