Re: EPICS Base Library sonames

["Johnson, Andrew N." <anj@aps.anl.gov>]

I will change SHRLIB_VERSION and LOADABLE_SHRLIB_VERSION in CONFIG_BASE to set them to EPICS_SHORT_VERSION so Base libraries will get sonames like libca.so.3.15.0.2 or 3.15.1

For most architectures only Base libraries get our version numbers; applications have to set SHRLIB_VERSION themselves if they want numbered shared libraries. On Darwin though we are currently overriding SHRLIB_VERSION in configure/os/CONFIG.darwinCommon.darwinCommon and that setting (currently 3.15.0) is used even for application libraries. 

I’ve just fixed that to disable SHRLIB_VERSION for Darwin applications, but Darwin does only allows at most 3 levels of numbering, which is why we were overriding it with an explicit value. Its linker takes flags -current_version <number> and -compatibility_version <number> arguments and we were setting these to 3.15.0 and 3.15 respectively, which we agree is incorrect for our binary compatibility promises. I propose using the 3-level SHRLIB_VERSION for both flags in Base, but an application could easily break building on MacOS if they use a 4-level number, and we don’t have a way for an application to provide two separate values for these. Should we worry about this?

- Andrew


On Oct 9, 2014, at 3:07 AM, Ralph Lange <Ralph.Lange@gmx.de> wrote:

> Hi Andrew,
> 
> On 08/10/2014 23:24, Andrew Johnson wrote:
>> 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.
> 
> I am only asking again as between 3.14 and 3.15 we have been changing our numbering system: basically pulling one level up, so that minor releases - the "15" in 3.15 - are now expected to change as often as versions - the "12" in 3.14.12 - used to.
> 
> I wanted to make sure we are still not promising binary compatibility even at the patch level. (Which I think we could consider if we saw benefit .)
> 
>>> 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.
> 
> Still:
> > objdump -p ../V3/3.15/tip/lib/linux-x86_64/libCom.so.3.15 | grep SONAME
>  SONAME               libCom.so.3.15
> 
> Which I find misleading or even wrong given that we do not promise binary compatibility even between patch levels, i.e. two digits down.
> 
>> 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.
> 
> Interesting.
> As a first step, though, I find it more important to make the SONAME of the created libraries match the level of binary compatibility that we promise.
> That would help packaging EPICS Base a lot. The automated tool ... yes, nice to have when we start promising anything in this regard.
> 
> Cheers,
> ~Ralph
>