...

}

Dynamic Path Lookup

If you specify an embedded path while building the filtered shared library using the +b linker option, the dynamic loader attempts to use this dynamic path when it searches for the implementation library to load. For example:

$ ld -b impl1.o -o libimpl1.sl

$ ld -b +b /path/to/implementation/libs +filter\ ./libimpl1.sl -o libfilt.sl $ chatr +b enable libfilt.sl

$ cc prog.c libfilt.sl -o prog

$ mv libimpl1.sl /path/to/implementation/libs $ ./prog

Thread-Private Data (TLS)

You can use TLS in the implementation libraries even though they are "`lazy-loaded". When the filter library is loaded, space is reserved for the TLS of its implementation libraries even before they are loaded. Because the space is reserved, filtering is not an appropriate way to reduce TLS consumption.

Maintaining filtered shared libraries

To maintain your filtered shared libraries, you must rebuild them when you make the following changes:

Add or remove symbols from the set of exported symbols from the implementation libraries

Change symbol types, for example, when an uninitialized data symbol (BSS symbol) is changed to an initialized data symbol (or vice-versa), or a text symbol into a data symbol.

Change the TLS (Thread Local Storage) size of an implementation library Even though the newly-added TLS symbols may not be exported outside the implementation library, you must rebuild the filter library so the correct amount of TLS space is reserved. To see the TLS size, use the following command:

$ odump -sldlheader shared_library_pathname fgrep tdsize

Function Level Versioning

A new type qualifier with syntax '__attribute__((version_id("<some version id string>"))' is supported that can be used to facilitate shared libraries to have different versions of the same function based on platform (11.0, 11.11 etc.) or any other factor. Existing user applications using these shared libraries do not require recompilation when migrated to next version of the OS. Binaries will continue to run with the older version of the function which is part of the shared library.

Example usage:

extern int y __attribute__((version_id("11.22")));

Version Control with Shared Libraries

HP-UX provides a method to support incompatible versions of shared library routines. “Library-Level Versioning” (page 111) describes how to create multiple versions of a shared library.

NOTE: Beginning with the HP-UX 11.00 release, the linker toolset supports only library-level versioning. Previous releases supported inter-library version control.

When to Use Shared Library Versioning

For the most part, updates to a shared library must be completely upward-compatible; that is, updating a shared library does not usually cause problems for programs that use the library. But sometimes - for example, if you add a new parameter to a routine - updates cause undesirable

110 Creating and Using Libraries