2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: EPICS Base Library sonames |
From: | Ralph Lange <[email protected]> |
To: | EPICS Core-Talk <[email protected]> |
Date: | 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.15Which 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