0

There are similar questions but their answers did not work for my issue. I have a c++ program with #include <boost/test/unit_test.hpp> on top (among other includes).

To compile correctly, if I understood, I should do the command:

g++ -g -L/path_to_boost_lib -lboost_lib myprog.cpp -o myprog.exe

If i do a locate, I get /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so. Hence I edited my call to g++ by doing:

g++ -g -L/usr/lib/x86_64-linux-gnu -lboost_unit_test_framework myprog.cpp -o myprog.exe

But I still get errors of the type undefined reference to boost::unit_test.

I also tried the option -I/usr/include/ which contains the boost folder, without success.

Binou
  • 124
  • 9

1 Answers1

1

It's because of the order. The GCC linker goes through the artifacts left-to-right, and every unknown symbol it encounters in an object file must be resolved by an artifact occurring afterwards.

The right command is thus:

g++ -g myprog.cpp -L/usr/lib/x86_64-linux-gnu -lboost_unit_test_framework -o myprog.exe

See this answer for a more thorough explanation.

I suggest using a build tool like CMake that takes care of such low-level details for you.

flyx
  • 35,506
  • 7
  • 89
  • 126
  • I definitely will have a look, thank you! Is there a specific order between options '-L' and '-I'? I thought everything was blocked due to boost but it seems that my include path has some issue too... And I don't really understand because the include in my header is a relative path, i.e. `#include "../../folder1/folder2/otherfile.h` and this path is correct from my main program which I want to compile – Binou Dec 01 '19 at 11:46
  • Relative includes should not depend on `-L`, and I am unsure whether order matters here but if it does, `-L` certainly must come before `-l`. If you have a problem with relative includes in your code, you should ask a new question. – flyx Dec 01 '19 at 12:45