Undefined opencv symbol in module

Question

I have installed the SDK, used the command to clone the example module, wrote my own, and compiled.   Used the command to insert the video mapping into the configuration.

When I try to run the daemon with my module, I get an error during runtime, when it looks for the OpenCV symbol   findHomography:

INF Engine::Engine: Loaded 48 vision processing modes.
INF Engine::onParamChange: Using [stdio] hardware (4-pin connector) serial port
INF Engine::onParamChange: No USB serial port used
INF Engine::postInit: Initalizing Python...
INF Engine::postInit: Starting camera device /dev/video0
INF Camera::Camera: [9] V4L2 camera /dev/video0 card Integrated_Webcam_HD bus usb-0000:00:14.0-11
INF Engine::postInit: Using display for video output
INF Engine::setFormatInternal: OUT: YUYV 640x480 @ 28.5fps CAM: YUYV 640x480 @ 28.5fps MOD: amir:floortrack
INF Camera::setFormat: Camera set video format to 640x480 YUYV
INF Engine::setFormatInternal: Instantiating dynamic loader for /jevois/modules/amir/floortrack/floortrack.so
INF Engine::setFormatInternal: Module [floortrack] loaded, initialized, and ready.
INF Camera::streamOn: 6 buffers of 614400 bytes allocated
INF READY JEVOIS 1.3.0
Score: 32520
jevois-daemon: symbol lookup error: /jevois/modules/amir/floortrack/floortrack.so: undefined symbol: _ZN2cv14findHomographyERKNS_11_InputArrayES2_idRKNS_12_OutputArrayEid

Answer 1

Seems that my assumption that the appropriate opencv libraries are automatically linked was incorrect.

The solution was to add the required library   opencv_calib3d  to the list of libraries in the CMakeLists.txt

Comments

thanks for noting, indeed, only the minimum set of required OpenCV libs in linked in by default, and you do need to add any extra ones to your CMakeLists.txt

---

That makes sense, but it would be preferable to get a warning/error during compile time, and not runtime.

---

yes, we will look into it but it may not be possible because the JeVois modules are themsleves compiled as shared objects (as opposed to full executables) to allow runtime loading/unloading.

---

Solving the general case would indeed be problematic.  But solving a smaller subset should be doable.   I'm thinking running ldd  on the resulting .so  and comparing only the list of dependent libopencv_*   to the list of items in the cmake cfg.    Then just give a warning if there's a mismatch.    It will only provide partial solution, but since most opencv programs only using a single include, it's sometimes hard to notice when you've crossed over to a new lib territory.