Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Multiple OS Build
From: Ron Sluiter <sluiter@aps.anl.gov>
To: Mark Rivers <rivers@cars.uchicago.edu>, Hugo Slepicka <hhslepicka@gmail.com>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Mon, 9 Jan 2017 14:57:18 -0600
Agreed. In addition to areaDetector, we have ran into this with Mark Clift's Galil motor controller support; it requires the newer version of the GNU Compiler Collection that comes with RHEL7. So what we are doing now is deploying local copies of EPICSbase and synApps built and ran only on RHEL7 workstations until the beamlines are all upgraded to RHEL7. Flexibility or simplicity; chose one.

What I failed to mention on my earlier post was that the reason I had to create that document was so that I could remember which EPICS_HOST_ARCH would build against which version of VxWorks. I you are not doing cross-compiling across different OS versions, the situation is not as complicated so that creating and maintaining OS version specific EPICS_HOST_ARCH's is probably more manageable. That has not been our (BCDA's) situation.

On 1/9/2017 1:59 PM, Mark Rivers wrote:

Hi Ron,

 

The problem with this approach is that it does not work when an EPICS application needs to use a vendor library built with a newer version of glibc on Linux, or Visual Studio C++ on Windows.  For example, the Point Grey vendor library won’t build on RHEL 6.  It also won’t work when the vendor library requires and older version than you are using.  For example, the last I heard the old Pilatus 100K detectors must run Linux version  2.6.27.39, which is gcc 4.2.1.  So they won’t work with your builds on RHEL 6 with gcc 4.4.6.

 

Mark

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Ron Sluiter
Sent: Monday, January 09, 2017 1:46 PM
To: Hugo Slepicka; tech-talk@aps.anl.gov
Subject: Re: Multiple OS Build

 

Hello Hugo,

I wrote the following for a related issue. 1st, some explanation. This method was given to me by Andrew Johnson (APS) and Janet Anderson (retired).  "BCDA" (Beamlines Controls and Data Acquisition) is my home group here at the APS. "dserve's" refers to hard disk servers that we use to make various versions of EPICSbase and synApps available to all our beamlines for building EPICS IOC's.

Maintaining EPICS Build Host Backward Compatibility

In order to maintain compatibility across multiple RHEL OS versions (e.g. RHEL6 & RHEL7) at the beamlines, BCDA must use a workstation with the oldest OS version available when building software (e.g. EPICS base & synApps) for distribution on the shared dserve's. If this is not done, then utilities that use OS shared runtime libraries (e.g., EPICSbase's "antelope") will be built with links to newer versions of libraries that do not reside on workstations with older OS versions. When workstations with the older OS run that utility, they fail. The assumption with this method is that newer OS versions will always be backward compatible with the older version.

We tried doing something similar to your "possible solution"; we created OS version specific EPICS_HOST_ARCH's; e.g., linux-x86_64-el5,  linux-x86_64-el6. It was unwieldy and difficult to remember which versions of synApps supported which OS versions, so we abandoned it for the above method. It is still somewhat complicated (see attached), but supporting a limited number of  EPICS_HOST_ARCH's helps.

Ron

On 1/9/2017 11:36 AM, Hugo Slepicka wrote:

Hi All,

I would like some input from the community regarding the organization of EPICS build for multiple OS targets (not cross-compiling), e.g. RHEL (5, 6, 7), Debian and other flavors available to coexist in a shared directory structure.

 

How is the community handling cases similar to rhel7-x86_64 versus rhel6-x86_64 given that "EPICS_HOST_ARCH" returns "linux-x86_64" for both?

One possible solutions would be to use something like:

       <shared_path>/<os_version>/base/.../<EPICS_HOST_ARCH>/...

       - where os_version would be: rhel5, rhel6, deb7, deb8, etc.


Another solution would be to apply a local patch to the EPICS building system to return a specific value for EPICS_HOST_ARCH including the <os_version>, e.g. rhel6-x86_64, resulting in something like this:
       <shared_path>/base/.../<NEW_EPICS_HOST_ARCH>/...

 

 

Thanks,

Hugo

 

 



References:
Multiple OS Build Hugo Slepicka
Re: Multiple OS Build Ron Sluiter
RE: Multiple OS Build Mark Rivers

Navigate by Date:
Prev: RE: Multiple OS Build Mark Rivers
Next: Looking for someone to help building the control system of XAFS/XRF beamline at SESAME Messaoud Harfouche
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: RE: Multiple OS Build Mark Rivers
Next: Looking for someone to help building the control system of XAFS/XRF beamline at SESAME Messaoud Harfouche
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 14 Feb 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·