c++ executable link issue

Question

Well, this really has me for a few hours now :)

I have a c++ project, which uses cmake. I have link issue, which I cannot resolve. Below is only the link command of a final executable:

/usr/bin/c++ -std=c++0x CMakeFiles/calib_sfm.dir/calib_sfm.cpp.o \
    -o calib_sfm -rdynamic libviso.so -lboost_log -lboost_log_setup \
    -lboost_system -lboost_filesystem -lboost_thread -lpthread \
    /home/kreimer/opencv3.0/lib/libopencv_viz.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_videostab.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_video.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_ts.a \
    /home/kreimer/opencv3.0/lib/libopencv_superres.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_stitching.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_softcascade.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_shape.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_photo.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_optim.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_objdetect.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_nonfree.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_ml.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_legacy.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_imgproc.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_highgui.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_flann.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_features2d.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudawarping.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudastereo.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudaoptflow.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudaimgproc.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudafilters.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudafeatures2d.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudacodec.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudabgsegm.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudaarithm.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cuda.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_core.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_contrib.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_calib3d.so.3.0.0 \
    -ldl -lm -lpthread -lrt \
    /home/kreimer/opencv3.0/share/OpenCV/3rdparty/lib/libippicv.a \
    /home/kreimer/opencv3.0/lib/libopencv_cudawarping.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_legacy.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudaimgproc.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudafilters.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_video.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_objdetect.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_nonfree.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_ml.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_cudaarithm.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_calib3d.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_features2d.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_highgui.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_imgproc.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_flann.so.3.0.0 \
    /home/kreimer/opencv3.0/lib/libopencv_core.so.3.0.0 \
    -Wl,-rpath,/home/kreimer/alex.kreimer@gmail.com/Technion/projects/robil/viso/debug/src:/home/kreimer/opencv3.0/lib

which produces this:

libviso.so: undefined reference to `cv::DescriptorExtractor::compute(cv::_InputArray const&, std::vector<cv::KeyPoint, std::allocator<cv::KeyPoint> >&, cv::_OutputArray const&) const'
libviso.so: undefined reference to `cv::calcHist(cv::Mat const*, int, int const*, cv::_InputArray const&, cv::_OutputArray const&, int, int const*, float const**, bool, bool)'
libviso.so: undefined reference to `cv::DescriptorExtractor::~DescriptorExtractor()'
libviso.so: undefined reference to `cv::namedWindow(cv::String const&, int)'
libviso.so: undefined reference to `cv::flann::SearchParams::SearchParams(int, float, bool)'
libviso.so: undefined reference to `cv::computeCorrespondEpilines(cv::_InputArray const&, int, cv::_InputArray const&, cv::_OutputArray const&)'
libviso.so: undefined reference to `cv::DescriptorExtractor::~DescriptorExtractor()'
libviso.so: undefined reference to `cv::destroyWindow(cv::String const&)'
libviso.so: undefined reference to `cv::imwrite(cv::String const&, cv::_InputArray const&, std::vector<int, std::allocator<int> > const&)'
libviso.so: undefined reference to `cv::imread(cv::String const&, int)'
libviso.so: undefined reference to `cv::cornerHarris(cv::_InputArray const&, cv::_OutputArray const&, int, int, double, int)'
libviso.so: undefined reference to `cv::FeatureDetector::detect(cv::_InputArray const&, std::vector<cv::KeyPoint, std::allocator<cv::KeyPoint> >&, cv::_InputArray const&) const'
libviso.so: undefined reference to `cv::waitKey(int)'
libviso.so: undefined reference to `cv::findEssentialMat(cv::_InputArray const&, cv::_InputArray const&, double, cv::Point_<double>, int, double, double, cv::_OutputArray const&)'
libviso.so: undefined reference to `cv::cvtColor(cv::_InputArray const&, cv::_OutputArray const&, int, int)'
libviso.so: undefined reference to `cv::FeatureDetector::~FeatureDetector()'
libviso.so: undefined reference to `typeinfo for cv::FeatureDetector'
libviso.so: undefined reference to `cv::Sobel(cv::_InputArray const&, cv::_OutputArray const&, int, int, int, int, double, double, int)'
libviso.so: undefined reference to `cv::FeatureDetector::empty() const'
libviso.so: undefined reference to `cv::undistortPoints(cv::_InputArray const&, cv::_OutputArray const&, cv::_InputArray const&, cv::_InputArray const&, cv::_InputArray const&, cv::_InputArray const&)'
libviso.so: undefined reference to `cv::DescriptorExtractor::empty() const'
libviso.so: undefined reference to `cv::FeatureDetector::~FeatureDetector()'
libviso.so: undefined reference to `cv::FeatureDetector::~FeatureDetector()'
libviso.so: undefined reference to `typeinfo for cv::DescriptorExtractor'
libviso.so: undefined reference to `cv::imshow(cv::String const&, cv::_InputArray const&)'
libviso.so: undefined reference to `cv::flann::IndexParams::~IndexParams()'
libviso.so: undefined reference to `cv::DescriptorExtractor::~DescriptorExtractor()'

Given that one of the missing symbols is a cv::namedWindow I do this:

nm -gC /home/kreimer/opencv3.0/lib/libopencv_highgui.so.3.0.0 | grep namedWindow
000000000002df80 T cv::namedWindow(cv::String const&, int)

So the symbol is present in a provided shared library. As I read around the order of the libraries does not matter for the dynamic build, so what could be the issue?

By the way, if I change the build of libviso to static instead of dynamic, as seen above, this executable links just fine.

score 1 · Answer 1 · answered Oct 17 '14 at 17:57

1

I have run into several similar problems in the past; I don't remember concrete examples, but I remember very well that the order of libraries matters; I ended up shuffling them until my project eventually built appropriately.

answered Oct 17 '14 at 17:57

Fabio A. Correa

1,968
1
17
26

The order of libraries on the command line absolutely does matter. – zwol Oct 17 '14 at 18:00
1

It matters when building static library/executable, but not dynamically linked one. At least thats what so suggests – Alex Kreimer Oct 17 '14 at 18:02
1

@AlexKreimer It matters always. Anything that says otherwise is wrong. – zwol Oct 17 '14 at 18:03
Link to some source? What should the order be? – Alex Kreimer Oct 17 '14 at 18:07

zwol · Accepted Answer · 2014-10-30T21:25:26.743

With a Unix-style linker, the order of the link command line always matters. All object files, .a files, .so files, and -l options are processed strictly left to right. Each item can resolve undefined symbols only for items to its left. You may have misunderstood documentation that's actually talking about the related bug that the linker people refuse to fix (going all the way back to Solaris 2.0, iirc) where shared libraries are unconditionally included whereas static libraries are not.

However, that's not the only problem, because libviso.so is one of the first things on the command line. I suspect what you have is a case of bad error messages, where the undefined symbols are being used by libviso.so and also something else much later on the command line, but are being attributed only to libviso.so.

There is a simple big-hammer fix: arrange to make your command line read as follows:

/usr/bin/c++ -std=c++0x CMakeFiles/calib_sfm.dir/calib_sfm.cpp.o -o calib_sfm \
    -rdynamic -Wl,--as-needed -Wl,--group \
    $(ALL_THE_LIBRARIES_HERE) \
    -Wl,--end-group \
    -Wl,-rpath,$(SAME_RPATH_AS_BEFORE)

The -Wl,--group ... -Wl,--end-group construction forces the linker to scan everything in between over and over again until it either has resolved all the undefined symbols or can prove conclusively that it just can't be done. Adding -Wl,--as-needed fixes the bug I mentioned earlier, so you won't suck in libraries you don't actually use.

Quote from the link by Fabio: "There is no requirements on the linking order of object files or dynamic libraries, though." I think I have also seen this in gcc docs. I will try what you suggest and let you know if it solves the issue. Thanks for your effort. — Alex Kreimer, Oct 18 '14 at 17:57
Dangerous as it is to say litb is mistaken, litb is, in fact, mistaken. He is correct to say that dynamic libraries, as well as object files, are unconditionally _included in the final executable_ (this is the bug I mentioned, corrected by `--as-needed`), but this _does not_ mean that the linker will search those libraries for undefined symbols from other libraries or objects later on the link line. — zwol, Oct 18 '14 at 18:58

c++ executable link issue

2 Answers2