Solaris 8 Software Developer Supplement

Chapter 10 Using appcert

appcert is new in the Solaris 4/01 release. For more information see, System Interface Guide.

This chapter discusses:

Note –

For the most current man pages, use the man command. The Solaris 8 Update release man pages include new feature information that is not in the Solaris 8 Reference Manual Collection.

Purpose of the appcert Utility

As new Solaris releases become available, some library interfaces might change their behavior or disappear entirely. Applications that rely on those interfaces would then stop functioning. The Solaris Application Binary Interface (ABI) defines runtime library interfaces that are safe and stable for application use. Applications that are written to conform with the Solaris ABI will remain stable under future releases of Solaris. The appcert utility is designed to help developers verify an application's compliance with the Solaris ABI.

What appcert Checks

The appcert utility examines your applications for:

Private Symbol Usage

Private symbols are functions or data that is used by Solaris libraries to call one another. The semantic behavior of private symbols might change, and symbols may sometimes be removed (such symbols are called demoted symbols.) The mutable nature of private symbols introduces the potential for instability in applications that depend on them.

Static Linking

Because the semantics of private symbol calls from one Solaris library to another might change between releases, the creation of static links to archives degrades the binary stability of an application. Dynamic links to the archive's corresponding shared object file avoid this problem.

Unbound Symbols

The appcert utility uses the dynamic linker to resolve the library symbols that are used by the application being examined. Symbols the dynamic linker cannot resolve are called unbound symbols. Unbound symbols might be caused by environment problems, such as an incorrectly set LD_LIBRARY_PATH variable, or build problems, such as omitting the definitions of the -llib or -z switches at compile time. While these examples are minor, unbound symbols that are reported by appcert might indicate a more serious problem.

What appcert Does Not Check

If the object file you want appcert to examine depends on libraries, those dependencies must be recorded in the object. To do so, be sure to use the compiler's -l switch when compiling the code. If the object file depends on other shared libraries, those libraries must be accessible through LD_LIBRARY_PATH or RPATH at the time you run appcert.

The appcert application cannot check 64–bit applications unless the machine is running the 64–bit Solaris kernel. Static linking checks are not performed by appcert when it is checking 64–bit applications.

The appcert utility cannot examine:

Working with appcert

To check your application with appcert, type:

appcert object|directory
replacing object|directory with either:

Note –

If appcert is run in an environment different from the one in which the application being checked would be run, the utility may not be able to resolve references to Solaris library interfaces correctly.

The appcert utility uses the Solaris runtime linker to construct a profile of interface dependencies for each executable or shared object file. This profile is used to determine the Solaris system interfaces upon which the application depends. The dependencies outlined in the profile are compared to the Solaris ABI to verify conformance (no private interfaces should be found).

The appcert utility recursively searches directories for object files, ignoring non-ELF object files. After appcert has finished checking the application, it prints a rollup report to the standard output (stdout, usually the screen). A copy of this report is written in the working directory, which is usually /tmp/, in a file named Report. In the subdirectory name, pid represents the 1– to 6–digit process ID of that particular instantiation of appcert. See appcert Results for more on the directory structure to which appcert writes output files.

appcert Options

The following options modify the behavior of the appcert utility. You can type any of these options at the command line, after the appcert command but before the object|directory operand.


Runs appcert in batch mode.

In batch mode, the report produced by appcert will contain one line for each binary checked.

A line that begins with PASS indicates the binary named in that line did not trigger any appcert warnings.

A line that begins with FAIL indicates problems were found in that binary.

A line that begins with INC indicates the binary named in that line could not be completely checked.

-f infile

The file infile should contain a list of files to check, with one file name per line. These files are added to any files already specified at the command line. If you use this switch, you do not need to specify an object or directory at the command line.


Prints usage information for appcert.


By default, appcert notes any shared objects in an application and appends the directories they reside in to LD_LIBRARY_PATH. The -L switch disables this behavior.


By default, appcert follows symbolic links when it searches directories for binaries to check. The -n switch disables this behavior.


Appends the Solaris library directories /usr/openwin/lib and /usr/dt/lib to LD_LIBRARY_PATH.

-w working_dir

Specifies a directory in which to run the library components and create temporary files. If this switch is not specified, appcert uses the /tmp directory.

appcert Results

The results of the appcert utility's analysis of an application's object files are written to several files that are located in the appcert utility's working directory (typically /tmp) The main subdirectory under the working directory is, where pid is the process ID for that instantiation of appcert.


Contains the mapping between checked binaries and the subdirectory in which appcert output specific to that binary is located.


Contains a copy of the rollup report displayed on stdout when appcert is run.


Contains a list of binaries that appcert was asked to check but was forced to skip, along with the reason each binary was skipped. These reasons are:

  • File is not a binary object

  • File cannot be read by the user

  • File contains metacharacters

  • File does not have the execute bit set


A separate subdirectory is under the objects subdirectory for each object examined by appcert. Each of these subdirectories contains the following files:



Contains a list of symbols appcert suspects are demoted Solaris symbols.



Contains a list of private Solaris symbols to which the object is directly bound. 



Contains a list of public Solaris symbols to which the object is directly bound. 



Contains a list of symbols not bound by the dynamic linker when running ldd -r. Lines returned by ldd containing “file not found” are also included.



Contains a printer-formatted summary of dynamic bindings in the objects appcert examined, including tables of public and private symbols used from each Solaris library.

When appcert exits, it returns one of four exit values.


No potential sources of binary instability were found by appcert.


The appcert utility did not run successfully.


Some of the objects checked by appcert have potential binary stability problems.


The appcert utility did not find any binary objects to check.

Correcting Problems Reported by appcert