VMS/IRAF Installation and Site Manager's Guide

VMS/IRAF Installation and Site Manager's Guide

9.7. Updating the full IRAF system

9.7.1. The BOOTSTRAP

All current IRAF distributions come with the system already bootstrapped, i.e., the host system interface (HSI) comes with the HSI binary executables already built. A bootstrap should not be necessary unless one is doing something unusual, e.g., installing a bugfix or making some other revision to the HSI.

A bootstrap is like a full system sysgen, except that it is the host system interface (kernel and bootstrap utilities) which is compiled and linked, rather than IRAF itself. The system must be bootstrapped before a sysgen is possible, since the bootstrap utilities are required to do a sysgen. The two operations are distinct because only the bootstrap is machine dependent; everything else works the same on all IRAF systems.

The bootstrap utilities are required for system maintenance of the main system and hence must be linked first. However, unless a bug fix or other revision is made to one of the main system libraries (particularly LIBOS), there should be no reason for a user site ever to need to bootstrap the system. The bootstrap utilities are linked with the option /NOSYSSHARE, hence they should run on most versions of VMS.

The bootstrap utilities are written in C, and the DEC C compiler is required to compile or link these utilities. The C compiler is not required to run the prelinked binaries distributed with the system. To recompile and link the bootstrap utilities, i.e., to "bootstrap" IRAF, enter the commands shown below. Note that the HSI is always recompiled during a bootstrap; there is no provision for merely relinking the entire HSI (some individual programs can however be relinked manually by doing a "mkpkg update" in the program source directory).

$ set default [iraf.vms]
$ set verify
$ @rmbin.com
$ @mkpkg.com
The bootstrap should take 30 to 45 minutes on an unloaded 11/780. Once the bootstrap utilities have been relinked and installed in hlib, the main system may be relinked.

9.7.2. Updating the system libraries

Updating the system libraries, i.e., recompiling selected object modules and inserting them into the system object libraries, is necessary if any system source files are edited or otherwise modified.

The system libraries may be updated either from within the IRAF CL, or from DCL. For example, from within DCL:

$ set def [iraf]
$ mkpkg syslibs [mathlibs]

The brackets around mathlibs just mean "optional"; do not actually include the brackets if you need to rebuild the math libraries. This command will run the mkpkg utility, which will update each system library in turn, descending into the tree of source directories and checking the date of each object module therein against the dates of the source files and dependency files used to produce the object module, and recompiling any object modules which are out of date. In the worst case, e.g., if the system libraries have been deleted, the entire VOS (virtual operating system) will be recompiled. If it is known that no changes have been made to the math library source files, the optional mathlibs argument may be omitted to save some time.

9.7.3. Relinking the IRAF shared library

The IRAF shared library ([IRAF.BIN]S_IRAF.EXE) is constructed by linking the contents of the four main IRAF system libraries LIBEX, LIBSYS, LIBVOPS, and LIBOS. Hence, the system libraries must exist and be up to date before linking the shared library. The shared library must be installed in bin before it can be used to link any applications programs. At present, the shared library does not use transfer vectors, hence the full system must be relinked following any changes to the shared library. Note that since the shared library is normally installed in system memory, all installed IRAF images should be deinstalled and later reinstalled whenever the shared library is rebuilt. IRAF will not be runnable while this is taking place.

In the current release of IRAF the procedure for building the shared library has not yet been integrated into the automatic system generation procedure. Furthermore, utility tasks in the main IRAF system are currently used to build the shared library, so it is necessary to have at least part of the main system functioning before the shared library can be built. These problems (and the transfer vector problem) will be fixed in a future release of VMS/IRAF.

The shared library is rebuilt from within a running IRAF system that provides at a minimum the three executables CL.EXE, X_SYSTEM.EXE, and X_LISTS.EXE. If these executables do not yet exist or are not runnable, rebuild them as follows. Note the use of the "-z" link flag to link the new executables without the shared library.

$ set default [iraf.pkg.cl]
$ mkpkg update lflags=-z
$ set default [iraf.pkg.system]
$ mkpkg update lflags=-z
$ set default [iraf.pkg.lists]
$ mkpkg update lflags=-z
Now startup the CL and change to the directory hlib$share, which contains the code used to build the shared library.
$ set default [iraf.local]
$ cl
    (cl starts up...)
cl> cd hlib$share
The following commands will rebuild the shared library and install it in bin. This takes ten minutes or so.
cl> cl < makeshare.cl
    (takes a while)
cl> mkpkg install
cl> purge
cl> logout
The system libraries can be updated (
§9.7.2) and the shared library rebuilt while IRAF is in use by normal users, however as soon as the command mkpkg install is executed (moving the new S_IRAF.EXE to bin) execution of normal user programs is at risk and one should kick all IRAF users off the machine and deinstall any installed IRAF images. The system may now be relinked and the newly linked shared library and images reinstalled, after which the system is ready for normal use again. Note that makeshare creates a load map s_iraf.map for s_iraf.e that should be deleted when no longer needed (it is quite large).

9.7.4. Relinking the main IRAF system

The following DCL commands may be entered to relink the main IRAF system, installing the newly linked executables in bin. Note that any IRAF executables that have been installed in system memory must be deinstalled and reinstalled (§8.2) following the relink.

$ set default [iraf]
$ mkpkg update
The command shown causes the full system to be relinked (or recompiled and relinked if any files have been modified) using the default compile and link switches defined in the global mkpkg include file hlib$mkpkg.inc. Any system wide changes in how the system is generated should be implemented by editing the contents of this file. For example, the default file supplied with the system includes the following line:
$set    LFLAGS  = ""            # default XC link flags
This switch defines the switches to be passed to the HSI bootstrap utility program xc to link the IRAF executables (no switches are given, hence the default link action will be taken). The switch "-z" may be included in the xc command line to link an executable directly against the system object libraries, rather than using the shared library. Hence, to relink IRAF without using the IRAF shared library (as is necessary for all but one system when there are multiple versions of IRAF simultaneously installed on the same machine) we would change the definition of LFLAGS as follows:
$set    LFLAGS  = "-z"          # default XC link flags
A full system relink takes approximately 30 minutes, or significantly less if the shared library is used. A full system compile and relink takes 9-24 hours depending upon the host system.
The above procedure only updates the core IRAF system. To update a layered product one must repeat the sysgen process for the layered system. For example, to update the NOAO package:

$ set default [iraf.noao]
$ mkpkg -p noao
Layered systems are completely independent of one another and hence must be updated separately.