EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS Base Library sonames
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Wed, 8 Oct 2014 16:24:21 -0500
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


Replies:
Re: EPICS Base Library sonames Michael Davidsaver
Re: EPICS Base Library sonames Ralph Lange
References:
EPICS Base Library sonames Ralph Lange

Navigate by Date:
Prev: EPICS Base Library sonames Ralph Lange
Next: Re: EPICS Base Library sonames Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS Base Library sonames Ralph Lange
Next: Re: EPICS Base Library sonames Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024