Re: Library versions, SONAMEs,and symbol versions
On Fri, Nov 08, 2019 at 01:04:14PM +0100, Steve Keller wrote:
> Could someone please explain how library version numbers, shared object
> names (SONAME), and symbol version are used in Debian?
>
This is a complex set of interactions (that I am fairly certain I do not
fully understand myself), but I'll try.
> - Why do many libraries have version numbers that don't match their
> SONAME? I often find that confusing.
>
Because changes which do not change the interface do not require a
SONAME change. In fact, changing the SONAME on every source version
changes sort of defeats the purpose of SONAME. Internal implementation
changes and certain compatible interface changes can be made without
changing the SONAME.
> - Shouldn't a shared library's interface not change under any
> circumstances unless it also changes its SONAME? AFAIUI, that's the
> whole idea behind SONAME: Interface and/or behavior changes always
> cause the SONAME to be changed.
>
For example, the return type of a function can be changed from bool to
int and that will not change the SONAME. Adding new members to a struct
will also usually not require a SONAME change. Adding new functions at
the end of a class (C++) I'm pretty sure will also not require a SONAME
change. However, changing the order or types of function parameters,
removing or renaming functions all require SONAME changes.
> If new versions of symbols like curl_easy_init@CURL_OPENSSL_4 are
> introduced, the old one must be kept for compatibility,
> i.e. curl_easy_init@CURL_OPENSSL_3.
>
I would think that to be the case, but this is where my knowledge of
this matter is weak.
> Otherwise, it's not even possible to install an old version of the
> library to make my-binary run. The problem is that the old library
> would need to change the symlink libcurl.so.4 to point to the old
> shared library file. And again, I think this kills the main idea of
> SONAMEs.
>
I'm not sure why libcurl3 installed a symlink called libcurl.so.4, as I
would have expected only libcurl.so.3, but that may be a pecularity of
the libcurl packaging.
In principle, Debian library packages are made in such a way that you
can retain old versions (assuming the dependcies remain intact)
alongside new versions. I seem to recall needing more than one libicu
on my system at some point. So, the current version, libicu63, provides
a symlink, /usr/lib/x86_64-linux-gnu/libicuio.so.63, while the previous
version, libicu57 (I think), provided a symlink,
/usr/lib/x86_64-linux-gnu/libicuio.so.57, that enabled both library
packages to be installed at the same time on the same system.
> - Given that some libraries don't do it that way, is there a way to
> run a binary with ignoring the symbol versions? I.e. I assuming that
> the function curl_easy_init@CURL_OPENSSL_4 will work with my-binary,
> can I run it using that new symbol instead of the old one, i.e. don't
> care about the symbol version?
I don't know that such a thing is possible without hacking the loader.
Symbol versions are supposed to allow for more fine-grained control of
library dependencies. For example, libc6 has had the same SONAME since
forever and uses symbol versioning to allow for version-specific
dependencies under the umbrella of a single SONAME that has not changed
for some time. This allows old applications to use newer versions and
find everything they need, while also allowing the building of new
applications the demand newer versions of the library implementing the
same SONAME.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: