UNIX/IRAF Site Manager's Guide

UNIX/IRAF Site Manager's Guide

3.2. Shared libraries

Among the UNIX based versions of IRAF, currently only Sun/IRAF supports shared libraries, although we are looking into adding shared library support to the other, mostly SysV based versions of IRAF. SunOS has an unusually powerful virtual file system architecture, and several years ago was one of the few UNIX systems supporting shared, mapped access to files. This is no longer the case however, and nowadays most versions of UNIX provide some sort of shared library facility. Shared libraries result in a considerable savings in disk space, so eventually we will probably implement the facility for additional platforms. In the meanwhile, if you are running IRAF on a system other than a Sun this section can be skipped.

Sun/IRAF provides a shared library facility for SunOS 4.0 and later versions of SunOS (but not for SunOS-3). All architectures are supported. So long as everything is working properly, the existence and use of the shared library should be transparent to the user and to the site manager. This section gives an overview of the shared library facility to point the reader in the right direction in case questions should arise.

What the shared library facility does is take most of the IRAF system software (currently the contents of the ex, sys, vops, and os libraries) and link it together into a special sharable image, the file Sn.e in each core system BIN directory (n is the shared image version number, e.g. "S6.e"). This file is mapped into the virtual memory of each IRAF process at process startup time. Since the shared image is shared by all IRAF processes, each process uses less physical memory, and the process pagein time is reduced, speeding process execution. Likewise, since the subroutines forming the shared image are no longer linked into each individual process executable, substantial disk space is saved for the BIN directories. Link time is correspondingly reduced, speeding software development.

The shared library facility consists of the shared image itself, which is an actual executable image (though not runnable on all systems), and the shared library, contained in the library lib$libshare.a, which defines each VOS symbol (subroutine), and which is what is linked into each IRAF program. The shared library object module does not consume any space in the applications program, rather it consists entirely of symbols pointing to transfer vector slots in the header area of the shared image. The transfer vector slots point to the actual subroutines.

When an IRAF program is linked with xc, one has the option of linking with either the shared library or the individual system libraries. Linking with the shared library is the default; the -z flag disables linking with the shared library. In the final stages of linking xc runs the HSI utility edsym to edit the symbol table of the output executable, modifying the shared library (VOS) symbols to point directly into the shared image (to facilitate symbolic debugging), optionally deleting all shared library symbols, or performing some other operation upon the shared library symbols, depending upon the xc link flags given.

At process startup time, upon entry to the process main (a C main for Sun/IRAF) the shared image will not yet have been mapped into the address space of the process, hence any attempted references to VOS symbols would result in a segmentation violation. The zzstrt procedure, called by the process main during process startup, opens the shared image file and maps it into the virtual space of the IRAF program. Once the IRAF main prompt appears (when running an IRAF process standalone), all initialization will have completed.

Each BIN, if linked with the shared library, will have its own shared image file Sn.e. If the shared image is relinked this file will be moved to Sn.e.1 and the new shared image will take its place; any old shared image files should eventually be deleted to save disk space, once any IRAF processes using them have terminated. Normally when the shared image is rebuilt it is not necessary to relink applications programs, since the transfer vector causes the linked application to be unaffected by relocation of the shared image functions.

If the shared image is rebuilt and its version number (the n in Sn.e) is incremented, the transfer vector is rebuilt the new shared image cannot be used with previously linked applications. These old applications will still continue to run, however, so long as the older shared image is still available. It is common practice to have at least two shared image versions installed in a BIN directory.

Further information on the Sun/IRAF shared library facility in given in the IRAF V2.8 system notes file. In particular, anyone doing extensive IRAF based software development should review this material, e.g., to learn how to debug processes that are linked with the shared image.