Is there a reason, why you build your shared libraries without a SONAME and version number? To ease setup and maintenance of build systems, we build packages for all third party libraries on all supported systems. The Debian package ecosystem fails to see the shared libraries as dependencies. Quoting from the dpkg-shlibdeps manual:
A public library has a SONAME and is versioned (libsomething.so.X). A private library (like a plugin) should not have a SONAME and doesn’t need to be versioned.
The packaging process treats libLexActivator.so or libLexFloat.so as private libraries and therefore fails to automatically detect the dependency. This behavior is conform to ‘The Linux Documentation Project’. The convention describes, that shared libraries should have a SONAME and a versioned suffix.
Would it be possible to build the libraries based on this convention?
Our libraries are proprietary and hence not distributed through package managers. Usually, customers link the libraries statically if using C/C++. In case of other languages, the library is required to be present in the same directory as their app (e.g. Python, Node.js, Java).
Since the LexActivator libs are not available for download through package repositories, hence this behaviour is intended.
