HP-UX Linker and Libraries User's Guide

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.
The library that exports a symbol, but does not contain implementation or storage for that symbol.filter
The library that contains implementation and storage for a symbol.implementation
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