appcert
ResultsThe 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 appcert
.pid,
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:
check.demoted.symbols | ||
Contains
a list of symbols |
||
check.dynamic.private | ||
Contains a list of private Solaris symbols to which the object is directly bound. |
||
check.dynamic.public | ||
Contains a list of public Solaris symbols to which the object is directly bound. |
||
check.dynamic.unbound | ||
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. |
||
summary.dynamic | ||
Contains
a printer-formatted summary of dynamic bindings in the objects |
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.
appcert
Private Symbol Use. Because private symbols
might change their behavior or disappear from one Solaris release to another,
an application that depends on private symbols might not run on a Solaris
release different from the one it was developed in. If appcert
reports private
symbol usage in your application, rewrite the application to avoid the use
of private symbols.
Demoted Symbols. Demoted symbols are functions or data variables in a Solaris library that have been removed or scoped locally in a later Solaris release. An application that directly calls such a symbol will fail to run on a release whose libraries do not export that symbol.
Unbound Symbols. Unbound symbols are
library symbols that are referenced by the application that the dynamic linker
was unable to resolve when called by appcert
. While unbound symbols are not always
an indicator of poor binary stability, they might indicate a more serious
problem, such as dependencies on demoted symbols.
Obsolete Library. An obsolete library
might be removed from Solaris in a future release. The appcert
utility flags any
use of such a library, because applications that depend on them will not function
in a future release that does not feature the library. To avoid this problem,
do not use interfaces from obsolete libraries.
Use of sys_errlist or sys_nerr. The use of the sys_errlist and sys_nerr symbols might degrade binary stability, as a reference might be made past the end of the sys_errlist array. To avoid this risk, use strerror instead.
Use of strong and weak symbols. The strong symbols that are associated with weak symbols are reserved as private because their behavior might change in future releases of Solaris. Applications should only directly reference weak symbols. An example of a strong symbol is _socket, which is associated with the weak symbol socket.