JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Programming Interfaces Guide     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


1.  Memory and CPU Management

2.  Remote Shared Memory API for Oracle Solaris Clusters

3.  Session Description Protocol API

4.  Process Scheduler

5.  Locality Group APIs

6.  Input/Output Interfaces

7.  Interprocess Communication

8.  Socket Interfaces

9.  Programming With XTI and TLI

10.  Packet Filtering Hooks

11.  Transport Selection and Name-to-Address Mapping

12.  Real-time Programming and Administration

13.  The Oracle Solaris ABI and ABI Tools

What is the Oracle Solaris ABI?

Defining the Oracle Solaris ABI

Symbol Versioning in Oracle Solaris Libraries

Using Symbol Versioning to Label the Oracle Solaris ABI

Oracle Solaris ABI Tools

appcert Utility

What appcert Checks

Private Symbol Usage

Static Linking

Unbound Symbols

What appcert Does Not Check

Working with appcert

appcert Options

Using appcert for Application Triage

appcert Results

Correcting Problems Reported by appcert

Using apptrace for Application Verification

Application Verification

Running apptrace

Interpreting apptrace Output

A.  UNIX Domain Sockets


Defining the Oracle Solaris ABI

The Oracle Solaris ABI is defined in the Oracle Solaris libraries. These definitions are done by means of the library versioning technology and policies used in the link editor and run-time linker.

Symbol Versioning in Oracle Solaris Libraries

The Oracle Solaris link editor and run-time linker use two kinds of library versioning: file versioning and symbol versioning. In file versioning, a library is named with an appended version number, such as When an incompatible change is made to one or more public interfaces in that library, the version number is incremented (for example, to In a dynamically linked application, a symbol bound to at build time might not be present in the library at run time. In symbol versioning, the Oracle Solaris linker associates a set of symbols with a name. The linker then checks for the presence of the name in the library during run-time linking to verify the presence of the associated symbols.

Library symbol versioning associates a set of symbols with a symbol version name, and number if that name has a numbering scheme, by means of a mapfile. The following is an example mapfile for a hypothetical Sun library,

        SUNW_1.2 {
        } SUNW_1.1;

        SUNW_1.1 {

        SUNWprivate {
            local: *;

This mapfile indicates that symbolA, symbolB, and symbolC are associated with version SUNW_1.1, symbolD and symbolE are associated with SUNW_1.2, and that SUNW_1.2 inherits all the symbols associated with SUNW_1.1. The symbol __fooimpl is associated with a different named set which does not have a numbered inheritance chain.

During build time, the link editor examines the symbols used by the application. The link editor records the set names in the application on which those symbols depend. In the case of chained sets, the link editor records the smallest named set containing all the symbols used by the application. If an application uses only symbolA and symbolB, the link editor records a dependency on SUNW_1.1. If an application uses symbolA, symbolB, and symbolD, the link editor records a dependency on SUNW_1.2, because SUNW_1.2 includes SUNW_1.1.

At run time, the linker verifies that the version names recorded as dependencies in the application are present in the libraries that are being linked. This process is a quick way to verify the presence of required symbols. For more details, see the Linker and Libraries Guide.

Note - The local: * directive in the mapfile means that any symbol in the library that is not explicitly associated with a named set is scoped locally to the library. Such locally scoped symbols are not visible outside the library. This convention ensures that symbols are only visible when associated with a symbol versioning name.

Using Symbol Versioning to Label the Oracle Solaris ABI

Since all visible symbols in a library belong to some named set, the naming scheme can be used to label the symbols' ABI status. This labeling is done by associating all private interfaces with a set name beginning with SUNWprivate. Public interfaces begin with other names, specifically:

These public, named sets are numbered with a major.minor numbering scheme. When a set includes new symbols, the set's minor version number increases. When an existing symbol changes in a way that makes the symbol incompatible with its previous behavior, the major version number of the set that includes that symbol increases. When an existing symbol changes incompatibly, the version number in the library's file name also increases.

The definition of the Oracle Solaris library ABI is therefore contained in the libraries, and consists of the set of symbols that are associated with symbol version names that do not begin with SUNWprivate. The pvs command lists the symbols in a library.