What are Shared Libraries?

The Dynamic Loader dld.sl

When an incomplete executable begins execution, the HP-UX dynamic loader (see dld.sl(5)) looks at the a.out file to see what libraries the a.out file needs during execution. In 32-bit mode, the startup code in crt0.o activates the dynamic loader. In 64-bit mode, the kernel activates the dynamic loader for a 64-bit a.out.The dynamic loader then loads and maps any required shared libraries into the process's address space — known as attaching the libraries. A program calls shared library routines indirectly through a linkage table that the dynamic loader fills in with the addresses of the routines. By default, the dynamic loader places the addresses of shared library routines in the linkage table as the routines are called — known as deferred binding. Immediate binding is also possible — that is, binding all required symbols in the shared library at program startup. In either case, any routines that are already loaded are shared.

Consequently, linking with shared libraries generally results in smaller a.out files than linking with archive libraries. Therefore, a clear benefit of using shared libraries is that it can reduce disk space and virtual memory requirements.

	NOTE: In prior releases, data defined by a shared library was copied into the program file at link time. All references to this data, both in the libraries and in the program file, referred to the copy in the executable file. With the HP-UX 10.0 release, however, this data copying is eliminated. Data is accessed in the shared library itself. The code in the executable file references the shared library data indirectly through a linkage pointer, in the same way that a shared library would reference the data.

Default Behavior When Searching for Libraries at Run Time

By default, if the dynamic loader cannot find a shared library from the list, it generates a run-time error and the program aborts. For example, in 32-bit mode, suppose that during development, a program is linked with the shared library liblocal.sl in your current working directory (say, /users/hyperturbo):

$ ld /opt/langtools/lib/crt0.o prog.o -lc liblocal.sl

In 32-bit mode, the linker records the path name of liblocal.sl in the a.out file as /users/hyperturbo/liblocal.sl. When shipping this application to users, you must ensure that (1) they have a copy of liblocal.sl on their system, and (2) it is in the same location as it was when you linked the final application. Otherwise, when the users of your application run it, the dynamic loader will look for /users/hyperturbo/liblocal.sl, fail to find it, and the program will abort.

In 64-bit mode, the linker records ./liblocal.sl.

This is more of a concern with non-standard libraries—that is, libraries not found in /usr/lib or /usr/lib/pa20_64. There is little chance of the standard libraries not being in these directories.

Caution on Using Dynamic Library Searching

If different versions of a library exist on your system, be aware that the dynamic loader may get the wrong version of the library when dynamic library searching is enabled with SHLIB_PATH or +b. For instance, you may want a program to use the PA1.1 libraries found in the /usr/lib/pa1.1 directory; but through a combination of SHLIB_PATH settings and +b options, the dynamic loader ends up loading versions found in /usr/lib instead. If this happens, make sure that SHLIB_PATH and +b are set to avoid such conflicts.