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
