Re: Library versions, SONAMEs,and symbol versions
On Friday, November 08, 2019 09:08:07 AM Roberto C. Sánchez wrote:
> On Fri, Nov 08, 2019 at 01:04:14PM +0100, Steve Keller wrote:
...
> > - 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.
The items mentioned in the next sentences make sense to me in that they don't
require a SONAME change, but I'm surprised that the return type of a function
doesn't require a change?
> 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
Reply to: