Binary Compatibility Issues

An Application Binary Interface, or ABI, defines the machine-level characteristics of the object program produced by a compiler. It includes the sizes and alignment requirements of basic types, the layout of structured or aggregate types, the way in which functions are called, the actual names of entities defined in a program, and many other features. Much of the C++ ABI for Solaris is the same as the basic Solaris ABI, which is the ABI for the C language.

Language Changes

C++ introduced many features (such as class member functions, overloaded functions and operators, type-safe linkage, exceptions, and templates) which did not correspond to anything in the ABI for C. Each major new version of C++ added language features that could not be implemented using the previous ABI. Necessary ABI changes have involved the way class objects are laid out, or the way in which some functions are called, and the way type-safe linkage ("name mangling") can be implemented.

The C++ 4.0 compiler implemented the language defined by the ARM. By the time the C++ 4.2 compiler was released, the C++ committee had introduced many new language features, some requiring a change in the ABI. Because it was certain that additional ABI changes would be required for as-yet unknown language additions or changes, Sun elected to implement only those new features that did not require a change to the ABI. The intent was to minimize the inconvenience of having to maintain correspondence of binary files compiled with different compiler versions. Now that the C++ standard has been published, Sun has designed a new ABI that allows the full C++ language to be implemented. The C++ 5.0 compiler uses the new ABI by default.

One example of language changes affecting the ABI is the new names, signatures, and semantics of the new and delete free-store functions. Another is the new rule that a template function and non-template function with the same signature are nevertheless different functions. This rule required a change in "name mangling," that created a binary incompatibility with older compiled code. The introduction of type bool also created an ABI change, particularly regarding the interface to the standard library. Because the ABI needed to change, aspects of the old ABI that resulted in needlessly inefficient runtime code were improved.

Mixing Old and New Binaries

It is an overstatement to say that object files and libraries compiled by the 4.2 compiler cannot be linked with object files and libraries compiled by the 5.0 compiler. The statement is true whenever the files and libraries present a C++ interface.

Sometimes a library is coded in C++ for convenience, yet presents only a C interface to the outside world. Put simply, having a C interface means that a client cannot tell the program was written in C++. More specifically, having a C interface means that all of the following are true:

• All externally-called functions have C linkage and use only C types for parameters and returned value.

• All pointers-to-function in the interface have C linkage and use only C types for parameters and returned value.

• All externally-visible types are C types.

• All externally-available objects have C types.

• No C++ exceptions escape from or are passed into the library.

• Use of cin, cout, cerr, or clog is not permitted.

If a library meets the C-interface criteria, it can be used where ever a C library can be used. In particular, such libraries can be compiled with one version of the C++ compiler and linked with object files compiled with a different version.

However, if any of these conditions are violated, the files and libraries cannot be linked together. If an attempted link succeeds, which is doubtful, the program does not run correctly.