Possible Duplicate:
Why does the order of '-l' option in gcc matter?
I'm starting to learn the Boost Unit Test framework. I have a minimal test suite:
#define BOOST_TEST_MAIN
#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE( test1 ) {
BOOST_CHECK( 2 == 1 );
}
First I compile the source:
g++ -c src/tests.cc -o src/tests.o
This completes with no errors. I can then link as follows:
g++ -o tests src/tests.o -lboost_unit_test_framework
This also completes with no errors. The resulting binary executes with the expected results. However, if I swap the order of src/tests.o
and -lboost_unit_test_framework
, I get linker errors:
g++ -o tests -lboost_unit_test_framework src/tests.o
src/tests.o: In function `main': tests.cc:(.text+0x29): undefined reference to `boost::unit_test::unit_test_main(bool (*)(), int, char**)' src/tests.o: In function `test1::test_method()': tests.cc:(.text+0x9d): undefined reference to `boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring, unsigned int, boost::unit_test::basic_cstring)' tests.cc:(.text+0x146): undefined reference to `boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring, unsigned int, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned int, ...)' src/tests.o: In function `__static_initialization_and_destruction_0(int, int)': tests.cc:(.text+0x24d): undefined reference to `boost::unit_test::ut_detail::auto_test_unit_registrar::auto_test_unit_registrar(boost::unit_test::test_case*, unsigned long)' src/tests.o: In function `boost::unit_test::unit_test_log_t::unit_test_log_t()': tests.cc:(.text._ZN5boost9unit_test15unit_test_log_tC2Ev[_ZN5boost9unit_test15unit_test_log_tC5Ev]+0x21): undefined reference to `vtable for boost::unit_test::unit_test_log_t' src/tests.o: In function `boost::unit_test::make_test_case(boost::unit_test::callback0 const&, boost::unit_test::basic_cstring)': tests.cc:(.text._ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE[boost::unit_test::make_test_case(boost::unit_test::callback0 const&, boost::unit_test::basic_cstring)]+0x1d): undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test::basic_cstring)' tests.cc:(.text._ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE[boost::unit_test::make_test_case(boost::unit_test::callback0 const&, boost::unit_test::basic_cstring)]+0x5d): undefined reference to `boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring, boost::unit_test::callback0 const&)' src/tests.o: In function `boost::unit_test::unit_test_log_t::~unit_test_log_t()': tests.cc:(.text._ZN5boost9unit_test15unit_test_log_tD2Ev[_ZN5boost9unit_test15unit_test_log_tD5Ev]+0xb): undefined reference to `vtable for boost::unit_test::unit_test_log_t' collect2: ld returned 1 exit status
Why does the order of my arguments cause linker errors?
When GCC performs linking, libraries are treated specially: Only symbols that are missing from object files that came before the library in the command line list are filled in from the library. If you have further object files after a library, missing symbols from that object are not looked up in the library.
In a nutshell, list your object files first and libraries at the end.
The traditional behavior of linkers is to search for external functions from left to right in the libraries specified on the command line. This means that a library containing the definition of a function should appear after any source files or object files which use it. This includes libraries specified with the short-cut -l option, as shown in the following command:
http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With