by Stefan Schneider
The Oracle Solaris Binary Compatibility Guarantee warrants that applications developed for Oracle Solaris 10 will work on Oracle Solaris 11 as long as they rely on public and stable programming APIs.
The ability to execute a well-formed Oracle Solaris 10 application on Oracle Solaris 11 is, however, not sufficient to guarantee a high-quality user experience. Oracle Solaris 11 incorporates 6 years of technology evolution, which might require configuration changes for the following reasons:
lpdwas replaced by
/usr/ucb/whoamiis now located in
None of these changes should affect well-implemented Oracle Solaris 10 applications. Applications that haven't adhered to the Oracle Solaris 10 coding and operation standards might, however, need some configuration changes.
Oracle is facilitating the transition to Oracle Solaris 11 with a set of tools and an adoption guide that can be used to plan the transition to Oracle Solaris 11, as shown in Figure 1.
Figure 1. Overview of the Transition Process
To ensure the well-managed transition of an application to Oracle Solaris 11, you should start by consulting the Oracle Solaris 11 ISV Adoption Guide. This guide is a checklist of the common reasons why an Oracle Solaris 10 application that is not properly designed might have problems on Oracle Solaris 11. The guide lists all currently known border cases that might create problems on Oracle Solaris 11.
In addition, the Oracle Solaris 11 End of Features (EOF) Notices page lists the retired software frameworks and legacy hardware that will not be supported on Oracle Solaris 11. This page can be used as an additional checklist to identify potential problems that an Oracle Solaris 10 application might have on Oracle Solaris 11.
Applications typically consist of many subcomponents and third-party components. You can assess the technical readiness of your applications using the resources mentioned in the previous section. However, assessing the readiness of third-party runtime components might prove to be more difficult.
The Oracle Solaris Preflight Applications Checker enables you to determine the Oracle Solaris 11 readiness of a working Oracle Solaris 10 application by generating HTML reports that can be used as qualified "to do" lists. Having such lists lowers costs, because valuable QA time and root-cause analysis time can be saved by addressing the reported issues instead of relying on initial QA runs to understand the underlying problems.
The Oracle Solaris Preflight Applications Checker comes with three separate components, which are shown in Figure 2:
Figure 2. Components of the Oracle Solaris Preflight Applications Checker
All interfaces in Oracle Solaris are versioned to ensure upward compatibility, and they are labeled as
private. Public interfaces are those that are intended for use by applications or middleware running on top of Oracle Solaris, while private interfaces are those intended to be used only by other Oracle Solaris interfaces.
Although the most problematic cases of binary incompatibility result from the use of private symbols, other issues can arise from unstable practices. Unstable practices include static linking of an Oracle Solaris shared object to the application at compilation time, since Oracle Solaris interfaces might change over time. As interfaces evolve, the interactions between a shared object that is statically linked and other Oracle Solaris libraries are at risk for binary incompatibility as well. Therefore, in the compatibility check phase, when static linking is noted in the profiles of the objects, the compatibility checking tool reports this condition as dangerous. In addition, heuristics are used for checking partial static linking by looking at particular symbols.
During the initial phase of a binary scan, all bindings and associated symbols that are used by the application are extracted. The compatibility checking tool uses the user-supplied application environment variable
LD_LIBRARY_PATH to determine the libraries being used by the application during runtime. This information is then parsed to determine the path names of the objects being examined and the symbol bindings into Oracle Solaris shared libraries. Another utility used during the profiling phase is the
elfdump command, which dumps the dynamic linking information that the objects depend on.
The static source code analysis module can check for compatibility issues in C/C++ source code, K shell, and other shell scripts. This module mainly checks for the use of removed, renamed, modified, or deprecated Oracle Solaris library functions and shell commands.
The runtime analysis module can run in an existing Oracle Solaris 10 test environment and report potential compatibility issues. This module of the tool uses DTrace to look into process details, and it might invoke other system tools available on Oracle Solaris 10 (as needed).
The tool can be configured to run with different scopes varying from system-wide checks to specific processes only.
The RunTime Analyzer tool can report known issues in the following cases:
Most applications will not cause any issues to be reported by the scanning tools, and they most likely will not face the issues discussed in the "Oracle Solaris 11 ISV Adoption Guide" or the Oracle Solaris 11 EOF page. Therefore, most applications will likely work out of the box on Oracle Solaris 11. However, some applications will report problems because they use outdated and deprecated frameworks and APIs. These applications will need fixes.
The Oracle Oracle Solaris 11 Preflight Applications Checker and the "Oracle Solaris 11 ISV Adoption Guide" enable you to make decisions about the mitigation of reported problems. For example, you might decide to use the Oracle p2v (physical to virtual) or v2v (virtual to virtual) tools to migrate an application from Oracle Solaris 10 into an Oracle Solaris 10 zone, which operates in Oracle Solaris 10 mode on Oracle Solaris 11.
Here are some additional resources:
|Revision 1.0, 11/02/2011|