OpenCV linker errors in ROS Fuerte (reopened #5437 from code.ros.org)

[meyerj]

This bug was already reported as #5437 on code.ros.org 9 months ago or at least the symptoms are the same. Although the bug was fixed by an update of the opencv.pc pkgconfig file, we again observe linker errors in jenkins for the fuerte version of our hector_worldmodel stack:

Linking CXX executable ../../bin/object_tracker
/usr/bin/ld: CMakeFiles/object_tracker.dir/object_tracker.o: undefined reference to symbol 'cv::fastFree(void*)'
/usr/bin/ld: note: 'cv::fastFree(void*)' is defined in DSO /opt/ros/fuerte/lib/libopencv_core.so so try adding it to the linker command line
/opt/ros/fuerte/lib/libopencv_core.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[5]: *** [../bin/object_tracker] Error 1

(from http://jenkins.willowgarage.com:8080/view/FbinP64/job/ros-fuerte-hector-worldmodel_binarydeb_precise_amd64/60/console)

Note that we did not change the stack since the initial release more than two months ago and the object_tracker does not use opencv directly, but only indirectly via the image_geometry package. image_geometry exports the opencv pkgconfig flags via its manifest.xml file, but this seems to be insufficient due to the wrong ordering of linked libraries in rosbuild for dependent packages.

In groovy, the export section in image_geometry/package.xml is totally missing and I am not sure why the package compiles without errors here, although cv data types are referenced in the image_geometry's pinhole_camera_model.h header file (http://jenkins.willowgarage.com:8080/view/GbinP64/job/ros-groovy-hector-worldmodel_binarydeb_precise_amd64/36/console).

On my own machine the stack compiles without errors in fuerte and groovy with the current versions of ros-groovy-opencv2 (2.4.3-6precise-20130125-0338) / ros-fuerte-opencv2 (2.4.2-0precise-20120908-1624) and ros-groovy-image-transport (1.10.0-0precise-20130129-0755) / ros-fuerte-vision-opencv (1.8.8-s1349900876~precise) from ros-shadow-fixed, but jenkins is using newer versions:

Selecting previously unselected package ros-fuerte-opencv2.
Unpacking ros-fuerte-opencv2 (from .../ros-fuerte-opencv2_2.4.2-0precise-20130202-0927-+0000_amd64.deb) ...
Selecting previously unselected package ros-fuerte-vision-opencv.
Unpacking ros-fuerte-vision-opencv (from .../ros-fuerte-vision-opencv_1.8.8-s1359887542~precise_amd64.deb) ...

Was there an update that could have caused the above linker error?

[vrabaud]

Thx for your very detailed report.

For Groovy it's normal that it works: catkin deals with all that properly (you don't need to export anymore, welcome to catkin :) ).

For Fuerte, nothing has changed in a while so this has to be upstream .... I'll ping the core team. In the meantime, you mention something very interesting: "image_geometry exports the opencv pkgconfig flags via its manifest.xml file, but this seems to be insufficient due to the wrong ordering of linked libraries in rosbuild for dependent packages.". What do you mean by that ? Thx.

[meyerj]

Your statement that the export section is not required anymore for catkin is correct, but I only for catkinized packages. I guess there are still a lot of rosbuild packages out there that just depend on opencv2 or image_geometry and expect the compiler and linker flags to be imported by rosbuild, without invoking the find_package() function in cmake directly.

In fuerte, many catkinized packages still export their flags in the manifest.xml file by invoking pkg-config in backquotes, e.g. roscpp.

Is there a mechanism in groovy's rosbuild that invokes pkgconfig to add the flags of required catkin packages for conventional rosbuild packages?

Edit: Okay, today I learned from Dirk that since groovy, rosbuild and rospack are responsible to collect the compiler and linker flags for all kind of packages (by invoking pkg-config internally), so I was indeed wrong here.

[meyerj]

Regarding the ordering of linker arguments:
I do not remember the exact details. I wrote a comment about that problem in #5437. The linker seems to parse the command line in reverse order starting at the last argument, and symbols from libraries or object files that stand earlier in the command line are not considered to resolve symbols in files mentioned later (or vice-versa?). This is the reason why the -l version of the package config file worked, and the version with absolute paths of cv libraries did not, as rosbuild ordered the -l flags differently.

http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html from the gcc manual contains some details about ordering of command line flags in the -l section.

The "is defined in DSO /opt/ros/fuerte/lib/libopencv_core.so so try adding it to the linker command line" error from jenkins seems to be related to argument ordering (e.g. from http://fedoraproject.org/wiki/UnderstandingDSOLinkChange). From that perspective, this issue could also be considered as a bug in rosbuild...

[meyerj]

Don't know why, but Jenkins is back to normal since a couple of minutes: http://jenkins.willowgarage.com:8080/view/FbinP64/job/ros-fuerte-hector-worldmodel_binarydeb_precise_amd64/61/console

We did a release of the hector_gazebo and hector_models stacks this afternoon, but they are not related to hector_worldmodel.

[vrabaud]

ok, opencv had indeed been re-released but that exact patch had not been applied .... Sorry for the inconvenience. Thx for your help, it really helped finding the issue.