GNOME Bugzilla – Bug 698627
opencv: doesn't build with opencv 2.4.5
Last modified: 2014-01-07 08:07:23 UTC
After relaxing the version check in configure.ac to allow building for 2.4.5, there are two problems: 1. There are 10 instances of redundant declaration warnings. 2. The final link step fails to resolve any opencv-provided references. That seems to be because the libtool link command generates the wrong command-line: instead of providing -l<libname> for the opencv libraries, it lists each one without a command-line switch as (e.g.) libopencv_calib3d.dylib, which libtool happily ignores. Not sure whether this is an artifact of building on OSX or whether opencv's pkgconfig/opencv.pc changed in this latest update. By manually fixing up these errors, I was able to compile and link the plugin.
If the redundant declarations warnings are caused by the OpenCV headers being broken you could do something like what was done in gst-omx for the Raspberry Pi: http://cgit.freedesktop.org/gstreamer/gst-omx/commit/?id=4974f75d916e703cb78244154218cf700a1567fd Please report this to the OpenCV folks though so they can get it fixed properly :) For the linking problem, libtool is converting all the -lsomelibrary to whatever it finds in the libsomelibrary.la file. It might be that something there is wrong, or indeed the pkg-config file of OpenCV has changed and now lists things not as -lsomelibrary but instead gives the path to the library file (which would just be wrong and should be reported to the OpenCV people).
Could you attach the opencv.pc file?
Created attachment 242478 [details] /usr/local/Cellar/lib/opencv/2.4.5/lib/pkgconfig/opencv.pkg
(In reply to comment #1) > If the redundant declarations warnings are caused by the OpenCV headers > being broken you could do something like what was done in gst-omx for > the Raspberry Pi: > http://cgit.freedesktop.org/gstreamer/gst-omx/commit/?id=4974f75d916e703cb78244154218cf700a1567fd > Please report this to the OpenCV folks though so they can get it fixed > properly :) > Okay, thanks for the tip; I hadn't seen those pragmas before. I should note that the header file that is the source of all of the redundant decls warnings (operations.hpp) has been dramatically changed on opencv's git master; they've been doing some substantial reorganization, so the problem in 2.4.5 may be transient. I'll try building against HEAD to see how it looks. > For the linking problem, libtool is converting all the -lsomelibrary to > whatever it finds in the libsomelibrary.la file. It might be that > something there is wrong, or indeed the pkg-config file of OpenCV has > changed and now lists things not as -lsomelibrary but instead gives the > path to the library file (which would just be wrong and should be > reported to the OpenCV people). It looks like TPM is taking a look at this one. Opencv 2.4.5 is the first version I've ever built, so I don't know whether opencv.pc file contents have changed recently or have never been correct on OSX. fwiw, it looks the same when I build from HEAD.
Can you append the .pc file here?
> Can you append the .pc file here? It's there already, even if mislabelled :)
(In reply to comment #6) > > It's there already, even if mislabelled :) Sorry about that!
> Libs: ${exec_prefix}/lib/libopencv_calib3d.dylib > ${exec_prefix}/lib/libopencv_contrib.dylib > ${exec_prefix}/lib/libopencv_core.dylib ... So I guess this is an issue in opencv then?
I agree it's upstream. Older versions of opencv used -lFOO as expected, on some platforms but not all (controlled by a cmake variable whose reason and value-determination I don't fully understand). Now all appear to use explicit paths to the shared libraries as of their git on 2012-02-03.
(In reply to comment #9) > I agree it's upstream. Older versions of opencv used -lFOO as expected, on some > platforms but not all (controlled by a cmake variable whose reason and > value-determination I don't fully understand). Now all appear to use explicit > paths to the shared libraries as of their git on 2012-02-03. I believe the commit you're talking about is 984eb99428def93c708898c2b20d2ee40349b28a , which is, for lack of a better term, substantial: 124 files changed, 16945 insertions(+), 17564 deletions(-) Does anyone feel up to the challenge of working through this with the opencv developers? I'm happy to give it a shot myself as a clueless newb otherwise.
I just tried to reproduce the reported link problem with a test program. Using libtool-2.4.2: $ glibtool --mode=link --tag=CC gcc foo.lo -o foo /sw/lib/libintl.3.4.3.dylib glibtool: link: gcc .libs/foo.o -o foo /sw/lib/libintl.3.4.3.dylib $ otool -L foo foo: /sw/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) it's not dropping the explicit-path library during linking. Todd, could you post a snippet of the build transcript so we can see if it's libtool omitting a library that is being passed to it, vs autotools not propagating the correct flags?
Daniel, the plot definitely thickens. libtool seems to behave differently with respect to the explicit-path libs depending on whether there's c++ in the mix. Here's what happens when I run make --just-print: echo " CXXLD " libgstopencv.la;/bin/sh ../../libtool --silent --tag=CXX --tag=disable-static --mode=link g++ -D_REENTRANT -I/Users/todd/gstreamer/include/gstreamer-1.0 -I/usr/local/Cellar/glib/2.36.0/include/glib-2.0 -I/usr/local/Cellar/glib/2.36.0/lib/glib-2.0/include -I/usr/local/opt/gettext/include -DGST_USE_UNSTABLE_API -DG_THREADS_MANDATORY -DG_DISABLE_DEPRECATED -Wall -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Werror -Wno-non-virtual-dtor -DGST_DISABLE_DEPRECATED -I/usr/local/Cellar/opencv/2.4.5/include/opencv -I/usr/local/Cellar/opencv/2.4.5/include -module -avoid-version -export-symbols-regex '^_*gst_plugin_.*' -no-undefined -o libgstopencv.la -rpath /Users/todd/gstreamer/lib/gstreamer-1.0 libgstopencv_la-gstopencv.lo libgstopencv_la-gstopencvvideofilter.lo libgstopencv_la-gstopencvutils.lo libgstopencv_la-gstcvdilate.lo libgstopencv_la-gstcvdilateerode.lo libgstopencv_la-gstcvequalizehist.lo libgstopencv_la-gstcverode.lo libgstopencv_la-gstcvlaplace.lo libgstopencv_la-gstcvsmooth.lo libgstopencv_la-gstcvsobel.lo libgstopencv_la-gstedgedetect.lo libgstopencv_la-gstfaceblur.lo libgstopencv_la-gstfacedetect.lo libgstopencv_la-gsthanddetect.lo libgstopencv_la-gstpyramidsegment.lo libgstopencv_la-gsttemplatematch.lo libgstopencv_la-gsttextoverlay.lo libgstopencv_la-gstmotioncells.lo libgstopencv_la-motioncells_wrapper.lo libgstopencv_la-MotionCells.lo -L/Users/todd/gstreamer/lib -L/usr/local/Cellar/glib/2.36.0/lib -L/usr/local/opt/gettext/lib -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -L/Users/todd/gstreamer/lib -L/usr/local/Cellar/glib/2.36.0/lib -L/usr/local/opt/gettext/lib -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl /usr/local/Cellar/opencv/2.4.5/lib/libopencv_calib3d.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_contrib.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_core.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_features2d.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_flann.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_gpu.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_highgui.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_imgproc.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_legacy.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_ml.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_nonfree.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_objdetect.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_ocl.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_photo.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_stitching.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_superres.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_ts.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_video.dylib /usr/local/Cellar/opencv/2.4.5/lib/libopencv_videostab.dylib -lgstvideo-1.0 ... and here's what libtool produces when I execute the above command, omitting --silent: libtool: link: rm -fr .libs/libgstopencv.exp libtool: link: /usr/bin/nm .libs/libgstopencv_la-gstopencv.o .libs/libgstopencv_la-gstopencvvideofilter.o .libs/libgstopencv_la-gstopencvutils.o .libs/libgstopencv_la-gstcvdilate.o .libs/libgstopencv_la-gstcvdilateerode.o .libs/libgstopencv_la-gstcvequalizehist.o .libs/libgstopencv_la-gstcverode.o .libs/libgstopencv_la-gstcvlaplace.o .libs/libgstopencv_la-gstcvsmooth.o .libs/libgstopencv_la-gstcvsobel.o .libs/libgstopencv_la-gstedgedetect.o .libs/libgstopencv_la-gstfaceblur.o .libs/libgstopencv_la-gstfacedetect.o .libs/libgstopencv_la-gsthanddetect.o .libs/libgstopencv_la-gstpyramidsegment.o .libs/libgstopencv_la-gsttemplatematch.o .libs/libgstopencv_la-gsttextoverlay.o .libs/libgstopencv_la-gstmotioncells.o .libs/libgstopencv_la-motioncells_wrapper.o .libs/libgstopencv_la-MotionCells.o | sed -n -e 's/^.*[ ]\([BCDEGRST][BCDEGRST]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d' | /usr/bin/sed 's/.* //' | sort | uniq > .libs/libgstopencv.exp libtool: link: /usr/bin/grep -E -e "^_*gst_plugin_.*" ".libs/libgstopencv.exp" > ".libs/libgstopencv.expT" libtool: link: mv -f ".libs/libgstopencv.expT" ".libs/libgstopencv.exp" libtool: link: sed -e 's,^,_,' < .libs/libgstopencv.exp > .libs/libgstopencv-symbols.expsym libtool: link: g++ -o .libs/libgstopencv.so -bundle .libs/libgstopencv_la-gstopencv.o .libs/libgstopencv_la-gstopencvvideofilter.o .libs/libgstopencv_la-gstopencvutils.o .libs/libgstopencv_la-gstcvdilate.o .libs/libgstopencv_la-gstcvdilateerode.o .libs/libgstopencv_la-gstcvequalizehist.o .libs/libgstopencv_la-gstcverode.o .libs/libgstopencv_la-gstcvlaplace.o .libs/libgstopencv_la-gstcvsmooth.o .libs/libgstopencv_la-gstcvsobel.o .libs/libgstopencv_la-gstedgedetect.o .libs/libgstopencv_la-gstfaceblur.o .libs/libgstopencv_la-gstfacedetect.o .libs/libgstopencv_la-gsthanddetect.o .libs/libgstopencv_la-gstpyramidsegment.o .libs/libgstopencv_la-gsttemplatematch.o .libs/libgstopencv_la-gsttextoverlay.o .libs/libgstopencv_la-gstmotioncells.o .libs/libgstopencv_la-motioncells_wrapper.o .libs/libgstopencv_la-MotionCells.o -L/Users/todd/gstreamer/lib -L/usr/local/Cellar/glib/2.36.0/lib -L/usr/local/opt/gettext/lib /Users/todd/gstreamer/lib/libgstvideo-1.0.dylib /Users/todd/gstreamer/lib/libgstbase-1.0.dylib /Users/todd/gstreamer/lib/libgstreamer-1.0.dylib -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lintl -Wl,-exported_symbols_list,.libs/libgstopencv-symbols.expsym Undefined symbols for architecture x86_64: "_cvAbsDiff", referenced from: MotionCells::performDetectionMotionCells(_IplImage*, double, double, int, int, long, bool, bool, int, motionmaskcoordrect*, int, motioncellidx*, cellscolor, int, motioncellidx*, long, char*, bool, int)in libgstopencv_la-MotionCells.o "_cvAdaptiveThreshold", referenced from: MotionCells::performDetectionMotionCells(_IplImage*, double, double, int, int, long, bool, bool, int, motionmaskcoordrect*, int, motioncellidx*, cellscolor, int, motioncellidx*, long, char*, bool, int)in libgstopencv_la-MotionCells.o [remaining undefined symbols omitted] Note that the dylib's specified in the libtool command line don't appear on the g++ line. However, if I remove MotionCells.cpp from the mix, libtool generates a gcc line that still doesn't find the referenced opencv symbols, but at least the generated link command includes the specified dylib's.
Is there still a problem? I don't get any, also works fine with 2.4.7 apparently.
Sorry, I haven't touched opencv for quite a while, and I was quite a bit more clueless about building these projects from source back then. If it works for you, I'm happy to call it resolved.