RE: Multiple OS Build

[Mark Rivers <rivers@cars.uchicago.edu>]

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