Re: SHRLIB_VESION Variable

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 8/28/22 00:20, Abdalla Ahmad via Tech-talk wrote:
> Hi
>
> How much is it important to set the SHRLIB_VERSION when building support modules?
SHRLIB_VERSION on *nix sets shared library SONAME.  This is how *nix mostly avoids
the sorts of library version issues known as "DLL hell" in the windows world.

Understanding ABI issues is time consuming, though imo. to some extent unavoidable
when spending time with *nix software packaging and deployment.

Personally, I think that SHRLIB_VERSION should always be set.  This is informed
partially by my experiences doing Debian packaging.  imo. a clear error like
"unable to find libxyz.so.1" is always preferable to an unclear error like
"missing symbol xyzSomeReallyLongName4".  Or worse wasting time on some inexplicable
crash, only to find that it goes away after rebuilding the dependent module.


> I know it is set by default to the base version when building EPICS base but it seems it is optional when building any support modules. I did this test in our RPM setup, I had all support modules built using asyn 4.41 and I deployed an RPM for asyn 4.42, doing “yum install stream-device” failed because it explicitly asked for asyn 4.41 “libasyn.so.4.41”. I unset the variable in the base and removed it in the support modules, it did update asyn and installed any module that uses asyn, but I am wondering how much this would affect compatibility and dependencies between modules.
Absent an analysis of what, if any, ABI changes happened between asyn 4.41 and 4.42,
I would treat them as incompatible.  So my most straightforward answer would be to
always rebuild dependent packages when updating a package.

Of course this is sometimes inconvenient.  This is one reason I like the Debian
policy of putting shared libraries into a separate package, and putting the
SONAME in that package name.

> $ dpkg -L libc6:amd64|grep 'libc\.so'
> /lib/x86_64-linux-gnu/libc.so.6
This allows multiple versions of a library to be installed at the same time,
even if only momentarily during an upgrade.

I'm not as familiar with the fedora/rhel world, although I think the same idea is used
with different naming schemes.  eg. I have a fedora VM with both "readline" and
"compat-readline5" RPMs installed.

I do find a reference that opensuse (also RPM based) policy is close to debian.

https://en.opensuse.org/openSUSE:Shared_library_packaging_policy