HP-UX Linker and Libraries User's Guide

$ ld -b impl1.o -o libimpl1.sl
$ ld -b impl2.o -o libimpl2.sl
$ ld -b +filter libimpl1.sl +filter libimpl2.sl -o libfilt.sl
This builds a filtered shared library libfilt.sl with two implementation libraries
libimpl1.sl and libimpl2.sl.
3. To confirm which implementation libraries are in the filter set, use odump to list the contents
of the filter library:
$ odump -filtertable libfilt.sl
Filtered Shared Library List Table for libfilt.sl:
NOTE: The +filter option takes effect only when you use the -b option.
The +filter option can be used in conjunction with the -L linker option or the LPATH environment
variable. For example:
$ ld -b -L. +filter impl1 +filter impl2 -o libfilt.sl
or
$ export LPATH=.
$ ld -b -L. +filter impl1 +filter impl2 -o libfilt.sl
The filtered shared library itself can contain definitions of some symbols which are not required to
be ``lazy loaded'' (typically those symbols that are always used, for example, exit(2) in case of
libc). For example:
$ ld -b a.o b.o...+filter libimpl1.sl +filter libimpl2.sl -o libfilt.sl
Building application programs linked to filtered shared libraries
When applications use filtered shared libraries, they link only to the filter library and not the
individual implementation libraries. At link time, the implementation libraries are transparent to
the application linking with the filter. At run time, the dynamic loader searches for symbol definitions.
If it finds a match with a symbol in the filter library, it loads the appropriate implementation library
that contains the actual definition of the required symbol. The following example demonstrates
compiling an application program with a filtered library:
$ cc prog.c libfilt.sl -o prog
You can explicitly link your program with an implementation library as well as with the parent
filtered library, but you lose any advantage offered by the filter library feature. The implementation
library is loaded as your program is run.
Run time behavior of filtered shared libraries
Symbols defined in implementation libraries are not directly available to the application. They are
accessible only via their parent filter library. Users of shl_* and dl* APIs need to use the handle
for the filter library to query or define symbols. This is to preserve compatibility for existing
applications.
Initializers
If declared as part of implementation libraries, initializers are called only when the implementation
library is loaded (as part of a symbol binding). The handle argument to the initializer points to the
filter library so that it can be used for shl_findsym(3X) or dlsym(3C). For example, you declare
your initializers as follows:
#include <dlfcn.h>
void initializer(void *handle, int loading)
{
...
ptr = dlsym(handle, "symname");
Creating Shared Libraries 109