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 appcert.pid, where pid is the process ID for that instantiation of appcert. The appcert utility's results are written to the following files:
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 that is 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 in the following list:
File is not a binary object
File cannot be read by the user
File name 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 that appcert suspects are demoted Oracle Solaris symbols.
Contains a list of private Oracle Solaris symbols to which the object is directly bound.
Contains a list of public Oracle 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 Oracle Solaris library.
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.
Private Symbol Use – An application that depends on private symbols might not run on a Oracle Solaris release different from the one in which it was developed. This phenomenon occurs because private symbols that occur in a given Oracle Solaris release might behave differently or not be present in another release. 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 Oracle Solaris library that have been removed or have been scoped locally in a later Oracle Solaris release. An application that directly calls such a symbol fails 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, unbound symbols might indicate a more serious problem, such as dependencies on demoted symbols.
Obsolete Library – An obsolete library might be removed from the Oracle Solaris operating system in a future release. The appcert utility flags any use of such a library. Applications that depend on such a library might 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. 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 Oracle Solaris releases. Applications should only directly reference weak symbols. An example of a strong symbol is _socket, which is associated with the weak symbol socket.