HP UX Software Transition Kit (STK) manual +condrodata Command-Line Option

Normally, the C compiler places constant data in the data space. If such data is used in a shared library, each process receives its own copy of the data. This may result in some performance degradation.

Use the +ESlit/+Olit=all option to place constant data in the .text text segment instead of in the data space. This results in one copy of the constant data being shared among all processes that use the library.

+cond_rodata Command-Line Option

The compiler option +cond_rodata allows more data to be placed in the read-only section. Normally, data with initializers that contain relocations are not placed in the read-only data sections. This option enables the linker to compute the proper section for initialized constant data.

The +cond_rodata compiler option is available only for programs on Itanium-based systems.

NOTE: The +ESlit/+Olit=all option requires that programs do not write into constant strings and data. Structures with embedded initialized pointers do not work because the pointers cannot be relocated. The pointers are in the read-only $TEXT$ space (PA32 system) and text segment (Itanium-based system). In this case, the linker outputs the error message Invalid loader fixup needed.

Using Filtered Shared Libraries (32-bit Mode Only)

Filtered shared libraries allow developers to reduce the memory footprint of their shared libraries by providing for deferred loading of shared libraries (load-on- bind, referred to as ``lazy loading''). Filtering divides up a large library into one filter and several implementation libraries.

filter	The library that exports a symbol, but does not contain implementation or storage for that symbol.
implementation	The library that contains implementation and storage for a symbol.

The user links with the filter library, but the real definitions of data and functions reside in the implementation libraries. At run time, only those implementation libraries that are actually used are loaded. Filtered libraries can be nested; an implementation library can itself be a filtered library containing other implementation libraries.

The linker provides the 32-bit +filter option, used with the -b option, to enable this mechanism.

$ld -b...+filter shared_library_pathname

If you divide a filtered shared library up into independent implementation libraries, the total memory consumption is reduced significantly if the application uses only a small portion of the library. This reduction is most significant when the shared library contains a large amount of static data which is not used by all applications.

It is important, when dividing a shared library into implementation libraries, that you keep them independent of each other. If there are dependencies between implementation libraries, the memory reduction benefits cannot be realized. Filtered shared libraries preserve compatibility because a filtered shared library appears as a single component to the application. You need to link only to the filter library, regardless of how many implementation libraries it is divided into.

Building Filtered Shared Libraries

Building filtered shared libraries requires several steps:

1.Build the independent implementation libraries which constitute a filter set. These implementation libraries contain the actual definitions of code and data symbols. Build these libraries like ordinary shared libraries using the -b linker option.

2.Build the filter library using the +filter linker option. Each implementation library which is part of the filter set is specified using the +filter option. For example:

108 Creating and Using Libraries