Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 09 Oct 2014 10:07:17 +0200

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System