To use library-level versioning in this situation, you must set up corresponding file system links to make sure older applications linked with the older libraries run with these libraries. Otherwise, older applications can end up running with newer shared libraries. In addition, you must include the absolute path name in the internal name of the new library. For example, in PA-32 mode, to make the above example work correctly with library-level versioning, first implement library-level versioning with the actual library /X/libapp.so and include the absolute path in the internal name of the new library:

$ mv /X/libapp.so /X/libapp.0

Rename old

version.

$ ld

-b

-o /X/libapp.1 +h /X/libapp.1 *.o

Create

new

version.

$ ln

-s

/X/libapp.1 /X/libapp.so

Set up

symbolic link.

Then set up the corresponding file system links:

$ ln -s /X/libapp.0 /tmp/libmine.0 $ ln -s /X/libapp.1 /tmp/libmine.1 $ rm /tmp/libmine.so

$ ln -s /X/libapp.so /tmp/libmine.so

Link to old version. Link to new version. Remove old link.

Link to the link.

Figure 11 Example for Creating File System Link to a Shared Library File in PA-32 Mode

With these links in place, the loader loads /X/libapp.0 while running the a.out file created above. New applications link and run with /X/libapp.1. For IPF/PA-64 mode programs, the dynamic loader only loads the library recorded in the dynamic load table. You must use library-level versioning, and create your PA-64 and IPF shared library with an internal name unless the library is not versioned in future.

Using shl_load(3X) with Library-Level Versioning

Once library level versioning is used, calls to shl_load(3X) must specify the actual version of the library to be loaded. For example, if libA.so is now a symbolic link to libA.1, then calls to dynamically load this library must specify the latest version available when the application is compiled, as shown below:

shl_load("libA.1", BIND_DEFERRED, 0);

This insures that when the application is migrated to a system that has a later version of libA available, the actual version desired is the one that is dynamically loaded.

Intra-Library Versioning (PA-RISC only)

Intra-library versioning is a second method of maintaining multiple incompatible versions of shared library routines. HP recommends library-level versioning over intra-library versioning. This section discusses the following topics:

“The Version Number Compiler Directive” (page 113)

“Shared Library Dependencies and Version Control” (page 114)

“Adding New Versions to a Shared Library” (page 114)

“Specifying a Version Date” (page 115)

The Version Number Compiler Directive

With intra-library versioning, you assign a version number to any module in a shared library. The version number applies to all global symbols defined in the module's source file. The version number

Version Control with Shared Libraries 113

Page 113
Image 113
HP UX Software Transition Kit (STK) Using shlload3X with Library-Level Versioning, Intra-Library Versioning PA-RISC only