HP UX Software Transition Kit (STK) manual Updating a Shared Library, Shared Library Location IPF

<current search list>--> libP--> libA--> libD--> libQ--> libB

The same behavior occurs for libraries that are explicitly loaded with shl_load, but without the BIND_FIRST modifier (see “BIND_FIRST Modifier” (page 171) for details). If BIND_FIRST is specified in the shl_load call, then the libraries in the load graph are inserted before the existing search list. For example, suppose libP is loaded with this call:

lib_handle = shl_load("libP.so", BIND_IMMEDIATE BIND_FIRST, 0);

Then, the resulting library search list is:

libP--> libA--> libD--> libQ--> libB--><current search list>

Updating a Shared Library

The ld command cannot replace or delete object modules in a shared library. Therefore, to update a shared library, you must relink the library with all the object files you want the library to include. For example, suppose you fix some routines in length.c (from the previous section) that gave incorrect results. To update the libunits.so library to include these changes, you must use this series of commands:

$ cc -Aa -c length.c

$ ld -b -o libunits.so length.o volume.o mass.o

Any programs that use this library will now be using the new versions of the routines. That is, you do not have to relink any programs that use this shared library. This is because the routines in the library are attached to the program at run time.

This is one of the advantages of shared libraries over archive libraries: if you change an archive library, you must relink any programs that use the archive library. With shared libraries, you need only recreate the library.

Incompatible Changes to a Shared Library

If you make incompatible changes to a shared library, you can use library versioning to provide both the old and the new routines to ensure that programs linked with the old routines continue to work. See “Version Control with Shared Libraries” (page 110) for more information on version control with Shared Libraries.

Shared Library Location (IPF)

You can place shared libraries in the same locations as archive libraries (see “Archive Library Location (IPF) ” (page 98) ). Again, this is typically /usr/lib/hpux32 and /usr/lib/hpux64 for application libraries, and system libraries. However, these are just suggestions.

A program can search a list of directories at run time for any required libraries. Thus, libraries can be moved after an application has been linked with them. To search for libraries at run time, a program must know which directories to search. There are three ways to specify this directory search information:

•Store a directory path list in the program with the linker option +b path_list.

•Define the SHLIB_PATH environment variable for use at run time.

•Use the LD_LIBRARY_PATH environment variable, and the +s option is enabled by default.

For details on the use of these options, see “Moving Libraries after Linking with +b” (page 41) and “Moving Libraries After Linking with +s and SHLIB_PATH” (page 43) .

Improving Shared Library Performance

This section describes methods you can use to improve the run-time performance of shared libraries. If, after using the methods described here, you are still not satisfied with the performance of your program with shared libraries, try linking with archive libraries instead to see if it improves performance. In general, though, archive libraries do not provide great performance improvements over shared libraries.

102 Creating and Using Libraries