Compatibility between different versions of librealsense.so and kernel driver?

[ttencate]

Scenario: we are deploying an application linked with librealsense to a number of machines running Ubuntu 16.04, which may have different versions of the library and driver installed.

As I read on #3270 there is no ABI compatibility between minor versions of the library. So if our application is linked with 2.34 and the machine has 2.36 installed, it will not work. We could pin both application and host system to a fixed version, but it would make upgrading needlessly difficult.

It seems to me that the best solution would be to link the application with librealsense statically. That would avoid the ABI incompatibility between the application and librealsense, but might create an incompatibility between the statically linked version of librealsense and the kernel drivers installed on the host system.

I couldn't find any documentation or guarantees about this. Can we rely on compatibility between these different versions? Or is the interface between the library and the kernel driver only compatible between the same minor versions as well?

[MartyG-RealSense]

Hi @ttencate When building librealsense with CMake, there is a build customization flag called BUILD_SHARED_LIBS that, when set to False instead of its default state of True, can make the output of the library a static library (LIB/A) instead of a dynamic link library (DLL) or a shared object (SO).

https://dev.intelrealsense.com/docs/build-configuration

More information about setting BUILD_SHARED_LIBS to False can be found in the link below:

#4709

Please let us know whether #4709 resolves your questions about compatibility between versions or whether you need further advice on the subject. Thanks!

[ttencate]

Thank you for your answer @MartyG-RealSense! I'm aware of what static libraries are and how to use them, and I'm confident I can resolve any linker errors along the lines of #4709 if they arise.

But the RealSense SDK consists of more than a library; it also contains a kernel module which is installed on the system independent of the RealSense client application, and loaded into the kernel. So static linking might not actually be enough. My question was therefore: what is the level of compatibility between different versions of the library and the RealSense kernel module? Does a stable (or backwards/forwards compatible) interface exist between the two, or do the minor versions need to match?

[MartyG-RealSense]

As far as I know, you are most likely to encounter an API version mismatch error when using some external module such as the Python or ROS wrapper if that external module is older than the librealsense version that you are using. I have not seen an API version mismatch error from just installing librealsense on its own.

In regard to kernel compatibility, a wide range of different Linux kernels are used with librealsense. The Supported Platforms section at the top of the release notes for each version lists which kernels are supported by that SDK verison.

https://github.com/IntelRealSense/librealsense/releases/

I have certainly seen cases of projects involving multiple computers where Linux kernel versions have been mixed and matched. For example, there was a case this week involving 3 installations, two of which had different versions of kernel 5.3 and one that had a version of 4.15.

#7099 (comment)

If you wish to avoid complications with kernels, there is the option of building librealsense with the backend method that is not reliant on Linux versions or kernel versions and does not need patching.

#6845 (comment)

However, if your project requires flexible patching in future then the backend method may not be suitable for you. The link below describes the advantages and disadvantages of the backend installation method compared to the usual methods such as compiling from source. Please scroll down the linked-to comment to the section headed What are the advantages and disadvantages of using libuvc vs patched kernel modules?

#5212 (comment)

[ttencate]

I'm not concerned about compatibility with our kernel. We use the stock kernel on Ubuntu 16.04 so that won't be a problem.

So the DKMS module that gets installed is some kind of kernel patch? I assumed it was a full device driver. That definitely makes life easier.

With "backend method" I assume you mean the rsusb backend (as opposed to some other backend, like the V4L2 backend). If we compile the SDK with this backend (that is, with FORCE_RSUSB_BACKEND=True), and link it statically (that is, with BUILD_SHARED_LIBS=False), then judging by this comment we don't even need to install anything RealSense related on the host system (we don't need the extra frame metadata). That is perfect, thanks for putting me on the right track!

[MartyG-RealSense]

Yes, I mean the RSUSB backend method that builds a source code folder from the SDK Releases page using CMake and the -DFORCE_RSUSB_BACKEND=true flag. It installs dependencies over an internet connection instead of through patching (you only need the internet connection for the installation).

The DKMS method, meanwhile, installs librealsense via packages instead of building and patching it manually from source code.

https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md