We are distributing 2 different open-source software packages that can make use of liblsl. For Linux, we distribute both software packages in our self-hosted apt repository, and we distribute liblsl deb packages as a dependency. Recently we ran into an issue: One of our software packages updated its dependency on liblsl from version 1.13 to version 1.14 while the other stayed at version 1.13. This led to a situation where we could not install both of our software packages simultaneously on the same machine.

We have investigated the issue a bit and want to suggest changes to the debian packaging of liblsl (if you are interested. If not, please feel free to close this issue).

Liblsl uses the full liblsl version to name the "soname" of the liblsl shared library on Linux. This has the following consequences if I compile a simple program on Linux that uses liblsl. I will first give a simple example:

#include <cstdio>
#include <lsl_cpp.h>
int main(int, char*[]) {
  printf("%s\n", lsl::library_info());
  return 0;
}

When I compile this program on Linux and link against liblsl with g++ c.cpp -llsl while liblsl 1.13.0 is installed, it will link against liblsl version 1.13.0 exactly:

$ ldd a.out 
	...
	liblsl.so.1.13.0 => /lib/liblsl.so.1.13.0 (0x00
	...

because

$ objdump -p /usr/lib/liblsl.so | grep SONAME
  SONAME               liblsl.so.1.13.0
$ ls -l /usr/lib/liblsl*
lrwxrwxrwx 1 root root      16 Nov 25  2020 /usr/lib/liblsl.so -> liblsl.so.1.13.0
-rw-r--r-- 1 root root 1273776 Nov 25  2020 /usr/lib/liblsl.so.1.13.0

You indicate with the full-version soname that there is no binary compatibility between any two liblsl versions: If I install an executable compiled against liblsl 1.13.0 and then upgrade the liblsl deb package to version 1.13.1, then my executable compiled against liblsl 1.13.0 can no longer execute. It wants to load liblsl .so.1.13.0, but this file is no longer available. Instead, file liblsl.so.1.13.1 is available, but the different "soname" indicates that there is no compatibility between 1.13.0 and 1.13.1.

I can imagine two different ways for you to make it easier for your users so that existing binaries continue to work after updating liblsl:

1. You may decide that the signified incompatibility between any two liblsl versions is unintended. You would have to tell your cmake build and packaging process a "soname" different from the full liblsl version for this to work.

2. You may decide that you do not want to deal with binary compatibility between liblsl versions, but provide a way for your users to have multiple verisons of liblsl installed simultaneously on Linux.

I can help investigating both options, but before that you should decide if the current situation is as intended for you, or if you want to fix it in one of the two suggested ways.