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.220.127.116.11 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?
On Oct 9, 2014, at 3:07 AM, Ralph Lange <[email protected]> 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
>>> 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 , bottom of page.)
>> Also see .
>> 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.
> > 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 
>> looks like it might be useful for that, but I haven't tried it.
> 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.
- EPICS Base Library sonames Ralph Lange
- Re: EPICS Base Library sonames Andrew Johnson
- Re: EPICS Base Library sonames Ralph Lange
- Navigate by Date:
Re: EPICS Base Library sonames Ralph Lange
Jenkins build is back to stable : epics-base-3.15 #123 APS Jenkins
- Navigate by Thread:
Re: EPICS Base Library sonames Ralph Lange
Re: EPICS base 18.104.22.168 Andrew Johnson