Sun/IRAF V2.11 Site Manager's Guide

3.1. Multiple architecture support

Often the computing facilities at a site consist of a heterogeneous network of workstations and servers. These machines will often have quite different architectures or operating systems. Since IRAF is a large system it is undesirable to have to maintain a separate copy of IRAF for each machine architecture on a network. For this reason IRAF provides support for multiple architectures within a single copy of IRAF. To be accessible by multiple network clients, this central IRAF system will typically be NFS mounted on each client. It should be noted however that it is not always possible to use the multiple architecture support within the core system to maintain a single IRAF source tree for the entire heterogeneous network. The Host System Interface (HSI) for IRAF ports is different for platforms as diverse as Sun and SGI so there should be a separate installation for each system to minimize difficulties (the update schedules usually differ as well so maintaining the same version is also more difficult). In the case of supporting SunOS and Solaris systems, or a single platform with multiple compiler options (e.g. DECStation Ultrix with the MIPS and/or DEC compilers), one installation is sufficient since it's generally only the binaries that will differ. Almost any combination of architectures may be supported by a single copy of an external package since these shouldn't have any host dependencies.

Multiple architecture support is implemented by separating the IRAF sources and binaries into different directory trees. The sources are architecture independent and hence sharable by machines of any architecture. All of the architecture dependence is concentrated into the binaries, which are collected together into the so-called BIN directories, one for each architecture. The BIN directory contains all the object files, object libraries, executables, and shared library images for an architecture, supporting both IRAF execution and software development for that architecture. A given system can support any number of BIN directories, and therefore any number of architectures.

In IRAF terminology, when we refer to an "architecture" what we really mean is a type of BIN. The correspondence between BINs and hardware architectures is not necessarily one-to-one, i.e., multiple BINs can exist for a single compiler architecture by compiling the system with different compilation flags, as different versions of the software, and so on. Examples of some currently supported software architectures are shown below.

 Architecture    System         Description

  generic     any        no binaries
  ssun        Sun-4      Sun SPARC under Solaris (RISC) architecture, integral fpu
  sparc       Sun-4      Sun SPARC (RISC) architecture, integral fpu
  pg          Sun-4      Sun/IRAF compiled for profiling
  linux       PC         PC platforms running Linux
  freebsd     PC         PC platforms running FreeBSD
  sx86        PC         PC platforms running Solaris x86
  alpha       Dec Alpha	 DEC Alpha running Digital Unix
  ddec        Decstation DEC Fortran version of DSUX/IRAF
  dmip        Decstation MIPS Risc Fortran version of DSUX/IRAF
  rs6000      IBM        IBM RS/6000 running AIX
  hp700       HP         HP 700 series running HPUX 10
  irix        SGI        SGI IRIX, MIPS cpu
  f2c         Macintosh  A/UX, using Fortran-to-C translation and GCC

Most of these correspond to hardware architectures or operating system options. The exceptions are the generic architecture, which is what the distributed system is configured to by default (to avoid having any architecture dependent binary files mingled with the sources), and the "pg" architecture, which is not normally distributed to user sites, but is a good example of a custom software architecture used for software development.

When running IRAF on a system configured for multiple architectures, selection of the BIN (architecture) to be used is controlled by the UNIX environment variable IRAFARCH, e.g.,

% setenv IRAFARCH ssun

would cause IRAF to run using the ssun architecture, corresponding to the BIN directory bin.ssun. Once inside the CL one can check the current architecture by entering one of the following commands (the output in each case is shown as well).

cl> show IRAFARCH
ssun

 
cl> show arch
.ssun

If IRAFARCH is undefined at CL startup time a default architecture will be selected based on the current machine architecture, the available floating point hardware, and the available BINs. The IRAFARCH variable controls not only the architecture of the executables used to run IRAF, but the libraries used to link IRAF programs, when doing software development from within the IRAF or host environment.

Additional information on multiple architecture support is provided in the system notes file for V2.8, file doc$notes.v28.