0

I've been compiling some codes and found that the -llibrary flag has no effect in linking. Haven't really dealt with C++ before, so may be a simple mistake...

Here is the command I am using:

compiling:

g++ -c -Wall -std=c++11 -I/usr/include/flycapture -I/usr/include/ -I/usr/local/include/opencv2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include/ -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include/  -I/usr/include/boost   FrameRateCounter.cpp -o FrameRateCounter.o
g++ -c -Wall -std=c++11 -I/usr/include/flycapture -I/usr/include/ -I/usr/local/include/opencv2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include/ -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include/  -I/usr/include/boost   SaveVideoClass.cpp -o SaveVideoClass.o
g++ -c -Wall -std=c++11 -I/usr/include/flycapture -I/usr/include/ -I/usr/local/include/opencv2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include/ -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include/  -I/usr/include/boost   SaveVideo.cpp -o SaveVideo.o

linking:

g++ -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/ -lopencv_core -lopencv_highgui -lopencv_imgproc -lopencv_videoio -lsigc-2.0 -lglibmm-2.4 -lglib-2.0  -lstdc++ -lncurses -lflycapture   FrameRateCounter.o SaveVideoClass.o SaveVideo.o -o saveVideo

The compiling worked okay, but when linking it gave me a lot of undefined reference error:

FrameRateCounter.o: In function  `FrameRateCounter::FrameRateCounter(unsigned long)':
FrameRateCounter.cpp:(.text+0x48): undefined reference to `Glib::Timer::Timer()'
FrameRateCounter.cpp:(.text+0x58): undefined reference to `Glib::Mutex::Mutex()'
FrameRateCounter.cpp:(.text+0x68): undefined reference to `Glib::Timer::start()'
...
SaveVideoClass.cpp:(.text+0x1512): undefined reference to `cv::VideoWriter::VideoWriter(cv::String const&, int, double, cv::Size_<int>, bool)'
SaveVideoClass.cpp:(.text+0x1541): undefined reference to `cv::VideoWriter::~VideoWriter()'
SaveVideoClass.cpp:(.text+0x1565): undefined reference to `cv::VideoWriter::isOpened() const'

...
SaveVideoClass.cpp:(.text+0x2ea): undefined reference to `FlyCapture2::Camera::IsConnected()'
SaveVideoClass.cpp:(.text+0x308): undefined reference to `FlyCapture2::Camera::Disconnect()'
SaveVideoClass.cpp:(.text+0x30d): undefined reference to `FlyCapture2::Error::operator!=(FlyCapture2::ErrorType const&) const'

Then, I removed all the -llibrary flags, and it gave me exactly the same error messages. That's the reason why I think these flags didn't take effect. But why?

Here's some output of pkg-config if it helps:

pkg-config --libs opencv

-L/usr/local/lib -lopencv_stitching -lopencv_superres -lopencv_videostab -lopencv_aruco -lopencv_bgsegm -lopencv_bioinspired -lopencv_ccalib -lopencv_dnn -lopencv_dpm -lopencv_fuzzy -lopencv_line_descriptor -lopencv_optflow -lopencv_plot -lopencv_reg -lopencv_saliency -lopencv_stereo -lopencv_structured_light -lopencv_rgbd -lopencv_surface_matching -lopencv_tracking -lopencv_datasets -lopencv_text -lopencv_face -lopencv_xfeatures2d -lopencv_shape -lopencv_video -lopencv_ximgproc -lopencv_calib3d -lopencv_features2d -lopencv_flann -lopencv_xobjdetect -lopencv_objdetect -lopencv_ml -lopencv_xphoto -lippicv -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_photo -lopencv_imgproc -lopencv_core

pkg-config --libs glib-2.0:

-lglib-2.0

pkg-config --libs glibmm-2.4:

-lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0

If anyone wants to take a look at the source code, here is the link.

Update:

The order doesn't seem to be the problem. Libraries are given before the objects, so they should be available to FrameRateCounter.o, SaveVideoClass.o, and SaveVideo.o

Charlie Lam
  • 111
  • 7
  • I am aware of the influence of orders. But here, all the libraries are given **before** my compiled objects, so they should be available to these objects. But somehow there is still the undefined reference error. – Charlie Lam Jan 09 '17 at 10:35
  • @CharlieLam You should do exactly the opposite actually, see the first answer of the duplicate - *"the library that needs symbols must be first, then the library that resolves the symbol."*. – Holt Jan 09 '17 at 10:42
  • @Charlie Lam. Not so. The typical linker uses libraries to resolve symbols (functions, statics, etc) that have been referenced in preceding objects. Putting libraries first on the command line therefore typically means those libraries are not used to resolve symbols. – Peter Jan 09 '17 at 10:43
  • Thanks, that's exactly the problem...I misunderstood the order I should be using. Feel free to post a separate answer if you like! – Charlie Lam Jan 09 '17 at 10:49

0 Answers0