Instruction Set Specific Shared Objects

The dynamic token $ISALIST is expanded at runtime to reflect the native
instruction sets executable on this platform, as displayed by the utility isalist(1).
This token is available for filters, runpath definitions, and dependencies. As this token
can expand to multiple objects, its use with dependencies is controlled. Dependencies
obtained with dlopen(3C), can use this token with the mode RTLD_FIRST. Explicit
dependencies that use this token will load the first appropriate dependency found.

Note - This token is obsolete, and might be removed in a future release
of Oracle Solaris. See Capability Specific Shared Objects for the recommended technique for handling instruction set
extensions.

Any string name that incorporates the $ISALIST token is effectively duplicated into
multiple strings. Each string is assigned one of the available instruction sets.

The following example shows how the auxiliary filter libfoo.so.1 can be designed
to access an instruction set specific filtee libbar.so.1.

In either case the runtime linker uses the platform available instruction list
to construct multiple search paths. For example, the following application is dependent
on libfoo.so.1 and executed on a SUNW,Ultra-2.

Reducing Filtee Searches

The use of $ISALIST within a filter enables one or more filtees
to provide implementations of interfaces defined within the filter.

Any interface defined in a filter can result in an exhaustive search
of all potential filtees in an attempt to locate the required interface.
If filtees are being employed to provide performance critical functions, this exhaustive filtee
searching can be counterproductive.

A filtee can be built with the link-editor's -z endfiltee option to indicate
that it is the last of the available filtees. This option terminates any
further filtee searching for that filter. From the previous SPARC example, if
the SPARCV9 filtee existed, and was tagged with -z endfiltee, the filtee searches would
be as follows.