printf
Figure 7-13. The Dynamic Loader at Work
Figure 7-13 shows how the dynamic loader (dId. sl) handles processes when a user invokes sh. A process is created with multiple stubs pointing to dId. sl.
In this example (more specifically for Series 700/800), two stubs are shown-one stub for Jopen(3S), other for printJ(3S)-both of which are in the same library. (All the platforms-Series 300/400/700/800-use a linkage table as well; Series 700/800 use stubs also.)
Memory Management 7-37
7
7
When sh requires printf, the process first uses its stub to dId. sl, which does the work of establishing the pointer to printf and replacing its own stub with a stub to printf. Thereafter, when the process needs printf, a stub is in place to go right to printf, without having to point back to dId. sl.
Note that in the second half of the diagram, the stub intended for fopen is in place, although still pointing to dId. sl. However, it is ready to be accessed and replaced by a stub pointing to fopen.
Pointers also exist from the libc routines to dId. sl, but are not illustrated.
Shared Libraries vs. Archived Libraries
Occasionally, you may prefer to use an archived library when you link your application, in order to insulate your application from future modifications to the library. You can prevent a library change from adversely affecting your application by linking in the archived version of the library.
Usually, however, an application program benefits from updates to a library.
Bug fixes and enhancements to a shared library result in automatic bug fixes and enhancements to a program that uses the library, and new features in a library should not affect an existing application. You can also use version numbers described in Programming on HP- UX to ensure that you execute a particular version when you do use shared libraries.
Another reason for using an archived library would be that the program will execute on another system that does not have the shared library. A program that uses a shared library cannot stand alone; the shared library must be present at run time. (An environment variable, SHLrB_PATH enables you to specify search path for shared libraries; see Programming on HP- UX.) By copying library code from an archive library into your program, you can prepare a program that is independent of any other system file.
Another difference between shared and archive libraries is performance. For object code to be shared, it must be position-independent; that is, the library cannot know where its code or data will reside while it is running, since different programs may place the library code and data at different addresses.
(Text might vary the first time the library is loaded and stay fixed until the last reference is gone; data will be at a different address for each program.)
7 -38 Memory Management
In most cases, the performance improvement resulting from using shared code and smaller executable files will outweigh the penalties of position-independent code. However, if your library will be used by only one running application at a time, it might perform better using an archive library.
Administering Shared Libraries
• Shared (not archived) libraries are the default implementation shipped. To use archived libraries when a shared library exists requires a special linker option.
• Consider carefully the path of shared libraries in the file-system tree. Unless the environment variable, SHLIB_PATH is used, the shared library must be found at run time at the same location (that is, at the same pathname) as it is found at link time, or the program will not run.
o Be very careful where you put /lib, /usr/lib, /usr/local/lib and /usr / contrib/lib. Mistakes can be harrowing!
For example, if /lib is not on the root volume, the system will try to use it before it is mounted. As a result, no / etc/rc commands (or their descendents) that depend on any libraries in /lib will be executable.
Since / etc/rc uses many commands that depend on /lib/ dld. sl and /lib/libc. sl, /lib must be in the root volume. (See fs( 4) in the HP- UX Reference for more information on volumes and file-system structure.)
• You can NFS mount /usr/local/lib, but consider that all programs that use shared libraries from that directory will execute a little bit more slowly.
(However, once the shared libraries are used, they remain in memory for a 7 while; the NFS mount will then degrade performance only minimally.)
• For security, /lib and /usr/lib should never to writable by all. If /usr /local is writable by all, root should not be executing any programs that use shared libraries from /usr/local/lib. This precaution will prevent a potential security problem-actions of a malicious user, who could replace a library in that directory, thereby compromising any program using it.
• Missing or incorrect critical shared libraries can be detected during the boot procedure. If this occurs, the system administrator can recover the libraries using recoversl(lM) or via a backup tape.
• For a more thorough discussion of shared libraries, refer to Programming on HP-UX.
Memory Management 7-39
7