Are minor subversions of OpenCV ABI compatible?

asked 2020-07-15 14:10:45 -0600

mvidelgauz gravatar image

updated 2020-07-16 04:49:39 -0600

I am building a library that internally uses OpenCV. On my development machine I have OpenCV 3.2 installed, but on some my target machines the version of OpenCV is 3.3.1. (And I cannot control what version my clients will install on their machines) As far as I know there is a general rule that two versions of a library with the same major version number should be ABI compatible. So my first question is: does OpenCV conform to this rule? Is the answer different for C and C++ interfaces? (Then I would change my code so that it will use only C functions)

(The partial answer I have found here - it says OpenCV 3.3.0 is 99.88% backward compatible and 3.3.1 is 95.78% backward compatible so given I ma using very limited subset of the entire OpenCV, I think I have good chances that my library will work with both versions.)

If it does (at least for C interface) then I have second question:

  1. The output of objdump -p /usr/lib/libopencv_core.so shows SONAME libopencv_core.so.3.2, which leads to:
  2. when my library is built the result of ldd libMyLib.so shows "libopencv_core.so.3.2

So why is OpenCV built with sonameindicating version "3.2" and not just "3"?

I have downloaded OpenCV sources and built them on my PC. I see CMAKE_SHARED_LIBRARY_SONAME_CXX_FLAG=-Wl,-soname, in the generated CMakeVars.txt file. Is there a way to configure cmake so that library will be built with -soname indicating only major version "3"? Or maybe there is a way to tell my linker to set DT_NEEDED field of my library so that it's run-time requirement will be relaxed?

edit retag flag offensive close merge delete

Comments

(at least for C interface)

you should NEVER use that, it was DEAD already with 3.x and will be entirely gone tomorrow, your code will not be maintainable in the very near future. and most abi changes will be exactly there, removing "dead sea api" cruft.

3.3.x versions are also a thing of the past (4 years ago !)

berak gravatar imageberak ( 2020-07-16 01:51:42 -0600 )edit

@berak Thank you for commenting, but I am not sure I fully understand what you mean. As of today Ubuntu 18 "by default" installs 3.2 if we do "apt-get install libopencv-dev" and python3 brings 3.3.1 ("apt install python3-opencv"). As I wrote at the beginning of my question I cannot control what OpenCV version my clients will install on their machines...

mvidelgauz gravatar imagemvidelgauz ( 2020-07-16 03:51:09 -0600 )edit

yea, sorry, comment above is a bit off-topic, i only wanted to deterr you from using anything from the deprecated c-api

berak gravatar imageberak ( 2020-07-16 04:02:44 -0600 )edit

you also could avoid all those problems by building / distributing a statically linked executable (so your users would not have to install any opencv version), wouldn't that be the better option ?

berak gravatar imageberak ( 2020-07-16 04:10:28 -0600 )edit

@berak Yes I considered static linking also, but OpenCV has has big dependencies list and I am not sure those dependencies will be ABI compatible with my statistically linked 3.X code if client has 3.Y on their machine.

mvidelgauz gravatar imagemvidelgauz ( 2020-07-16 05:35:16 -0600 )edit

true, statically linking will remove the deps to opencv libs, but not what those depend on.

but you can keep that to a minimum (gui / video handling (do you even use any of it ?)) using the supplied 3rd party code

berak gravatar imageberak ( 2020-07-16 10:44:01 -0600 )edit
1

@berak not sure what mean by gui / video handling, I do use video writer (saving avi) and imgshow sometimes for debugging purposes (not as official part of my lib functionality, but still..). Being pressed with time I already built a version of my lib statically linked with OpenCV and now my installation script only needs to install also libavcodec57, libavformat57 and ffmpeg. This can work as a beta build but I am not sure all my customers will be happy even with three system-wide additions I bring to their system. Ideally I would like to build a self-contained lib with the only external requirement that _some_ OpenCV 3 version is installed, without specifying minor subversion in my requirements.

mvidelgauz gravatar imagemvidelgauz ( 2020-07-16 13:14:26 -0600 )edit

OpenCV 3

we're at 4.4 currently, 5.0 on the horizon

berak gravatar imageberak ( 2020-07-16 14:22:34 -0600 )edit

@berak If I understand correctly currently the only way to install OpenCV on Ubuntu 18 is to build it from sources. And if I will link it statically to my.so I will still have to install a lot of dependencies on customer's machine (https://www.pyimagesearch.com/2018/08...). Unfortunately, I have a requirement to minimize system-wide impact of my package installation. As I mentioned before with static OpenCV 3 I need to install only libavcodec57, libavformat57 and ffmpeg. Btw, this created athe problem for me in Ubuntu 20, which doesn't have 57 versions in it's repository, only 58. Do you know if any of OpenCV 3.x version can work with 58th avcodec and avformat libs? I would then build my static OpenCV libs with 58.

mvidelgauz gravatar imagemvidelgauz ( 2020-07-23 05:58:58 -0600 )edit