7

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?

Community
  • 1
  • 1
Matthew
  • 28,056
  • 26
  • 104
  • 170

2 Answers2

12

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.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • By the way, this change probably happened in a recent version of gcc, I'm quite sure that in gcc 4.4 the order of libraries on the command line didn't matter (or gcc was more forgiving). – Matteo Italia Aug 12 '12 at 23:18
  • 3
    @MatteoItalia This behavior exists since at least gcc 3.1.1 http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Link-Options.html#Link%20Options. – log0 Aug 12 '12 at 23:36
  • @Ugo: that's curious, because I had some makefiles that stopped working for that reason only after upgrading from gcc 4.4. :S – Matteo Italia Aug 12 '12 at 23:42
  • 2
    @MatteoItalia I don't know, but this issue has been confusing new gcc users for quite a long time now. It's a pity. The common use is to link libraries with the entire program. The command line kung fu should be reserved to people that really want to do tricky stuff like linking a library with half of the objects... – log0 Aug 13 '12 at 00:01
  • @Ugo: A couple of comments, the first is that I would not call it *command line kung fu*, but *design*. In a good design, dependencies are clear and never cyclic. The linker command line is just the realization of that dependencies. The second is that at any rate, there are command line options to have the linker iterate over the list of libraries pulling them iteratively. This will be much slower than linear linking which is the reason that it is not done in the first case. – David Rodríguez - dribeas Aug 13 '12 at 02:26
  • This behaviour is due to the linker, `ld`, which is not part of GCC. If @MatteoItalia's makefiles broke it's probably because binutils was also changed. – Jonathan Wakely Aug 13 '12 at 23:16
3

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

Gir
  • 839
  • 5
  • 11