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. "S11.e" for
Solaris or "S7.e" for SunOS).
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. In fact this is
required in the current Solaris/IRAF implementation because of an
incompatability in a system library between Solaris versions, the correct
version of the shared image for the current OS version will be used
automatically.*
Further information on the Sun/IRAF shared library facility in given in the IRAF V2.8 system notes file (iraf$doc/notes.v28). 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.
*On Solaris systems different versions of the IRAF shared
library are
required for each Solaris version due to slight changes in the host network
libraries. In this case the shared image mapped is the file
Sn_ver.e where the ver used is the Solaris
release version (e.g. 5.5, 5.4, etc). For minor revision levels such as
Solaris 5.5.1 no shared image will be found (i.e. there is no S11_5.5.1.e)
and so the default S11.e will be used. In the distributed system S11.e is
a symlink to the S11_5.5.e shared image (which works correctly on Solaris
5.5.1 systems), you may need to change this link to point at a different
shared image depending on your Solaris version and the machine in question.