Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Wed, 08 Oct 2014 19:00:55 -0400

FYI for debian packaging I use the full release number in the soname.
I'd recommend the same for anyone worried about ABI compatibility.

/usr/lib/i386-linux-gnu/libCom.so.3.14.12.3

Also, on Linux there is no magic to sonames.  They must match exactly.

On 10/08/2014 05:24 PM, Andrew Johnson wrote:
> Hi Ralph,
> 
> On 10/08/2014 08:57 AM, Ralph Lange wrote:
>> I am asked for a local ITER decision regarding the numbering of EPICS
>> Base shared libraries in ITER's CODAC Core System.
>>
>> What I see is that the soname numbering is unchanged wrt 3.14, i.e.
>> -r--r--r-- 1 ralph ralph 3963210 Oct  6 13:04 libCom.a
>> lrwxrwxrwx 1 ralph ralph      14 Oct  6 13:04 libCom.so -> libCom.so.3.15
>> -r-xr-xr-x 1 ralph ralph 1844208 Oct  6 13:04 libCom.so.3.15
>>
>> Is it safe to assume that all shared libraries in 3.15 will be binary
>> compatible?
>> Given that we have C++ (code and APIs) in those libraries, which is more
>> likely to break compatibility than standard C stuff, I would say; no.
>> (See [1], bottom of page.)
> 
> Also see [2].
> 
> I would give a stronger response: Definitely not, EPICS has never
> promised binary compatibility even between patch releases. We're not
> really interested in keeping track of compatibility at that level of
> detail, so version numbers that we use are really just place-holders.
> 
>> If you agree: shouldn't the sonames include the next digit of the EPICS
>> version, to be safe?
> 
> That should be safer, but I don't know if our current build rules can
> cope with multiple levels of version numbering yet. Installing a shared
> library when SHRLIB_VERSION is set also causes a single soft-link to be
> created from lib.so to the actual lib.so.$(SHRLIB_VERSION) file. Our
> configure directory tree does not contain the string 'soname' anywhere,
> so we're not passing that option to the linker at all.
> 
> If there is an automated tool that can test shared-library compatibility
> and tell us when we would need to increment the version number on a
> library I'd be happy to run it in Jenkins and add an explicit
> SHRLIB_VERSION setting for each library built in Base. This tool [3]
> looks like it might be useful for that, but I haven't tried it.
> 
> - Andrew
> 
>> [1] http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
> 
> [2] https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
> 
> [3] http://ispras.linuxbase.org/index.php/ABI_compliance_checker
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System