$ 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 -Llinker 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