Shared libraries without SONAME and version number



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 ( A private library (like a plugin) should not have a SONAME and doesn’t need to be versioned.

The packaging process treats or 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?

Best regards,



Hi Marc,

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.


Hi Adnan,

That may be true for you, but we will distribute our - also proprietary - software in a private repository using package managers.

Maybe, but other languages are - thank God - not linked to C/C++. :smiley:

Regarding this point, do you recommend your customers to statically link the libraries?


You can create the .so.3 version named libs too as they are just symlinks (.so is just a symlink for .so.3).

Yes, we recommend static linking for c/c++ apps.


Okay, we will stick with the static libraries.