C H A P T E R 6 - Workarounds for 4.0, 4.1, and 4.2 Compilers

C H A P T E R 6

Workarounds for 4.0, 4.1, and 4.2 Compilers

This chapter provides information and workarounds for problems that arise as a result of incompatibilities between versions 4.0, 4.1, and 4.2 of the C++ compiler and subsequent releases.

6.1 Problems and Solutions

This section discusses the following issues:

Cache Version Differences May Cause Compilation Errors

C++ Interface Incompatibilities

Using Tools.h++

Using Multiple Template Repositories; -ptr Option Ignored

Linking With 4.0.1 Libraries Containing Pointers to const Member Functions

Linking With Libraries Compiled With Earlier Compilers

Mixing Object Code From Different Versions

6.1.1 Cache Version Differences May Cause Compilation Errors

When you upgrade your compiler, you are required to run CCadmin -clean on every directory that contains a SunWS_cache subdirectory (alternatively, you can use rm -rf SunWS_cache). Failure to do so can result in compilation errors such as the following:

SunWS_cache: Error: Database version mismatch <path>/SunWS_cache/CC_version.

"<path>/SunWS_cache/CC_state", line 3: Error: "" not allowed here. ** Assertion ** : 0

6.1.2 Interface Incompatibilities

Versions 5.0 through 5.7 of the C++ compiler are not binary compatible with versions 4.0, 4.1, and 4.2 of the C++ compiler unless you specify the -compat option when you compile with versions 5.0 through 5.7 of the compiler. The incompatibility is due to the changes in the class layouts, the calling sequences, and the way names are mangled to meet the requirements defined in the ANSI/ISO C++ Standard.

Versions 5.0 through 5.7 of the C++ compiler are binary compatible.

6.1.3 Tools.h++

The C++ compiler uses standard iostreams as the default. If you use Tools.h++ in standard mode, you must either use the -library=rwtools7_std option or include the libiostream library as shown in the following compiler option:

example% CC -library=rwtools7_std foo.cc -> uses standard iostreams

example% CC -library=rwtools7,iostream foo.cc -> uses classic iostreams

However, in compatibility mode (with the -compat compiler option), you cannot issue -library=rwtools7_std because the standard library is not available:

example% CC -compat foo.cc -library=rwtools7 -> compatibility mode, standard library not available

Do not specify -library=rwtools7, -library=rwtools7_dbg, -library=rwtools7_std, or -library=rwtools7_std_dbg with -library=stlport4. Tools.h++ is not supported with STLport.

The binaries produced by the options -library=rwtools7_std and -library=rwtools7,iostream are not compatible. If you use one of these options, you should use the same option on every C++ compiler command for compiling and linking.

6.1.4 Multiple Template Repositories

The template repository is no longer created by default. You must specify -instances=extern explicitly to cause the compiler to create the repository.

In C++ compilers prior to version 5.0, the -ptr flag was used to designate repositories for template instantiations. With versions 5.0 through 5.7 of the C++ compiler, the -ptr flag is no longer required, as the compilation system reads from the template repositories corresponding to the object files that it reads, and writes template instances into the repository contained in the directory of the output location specified by the CC command.

The -ptr option was obsoleted in the 5.5 C++ compiler. The compiler now ignores the -ptr option. Even though the option is ignored, you should remove -ptr from all compilation commands because, in a later release, it may be reimplemented with a different behavior.

Note that the template repository is no longer created by default. You must specify -instances=extern explicitly to cause the compiler to create the repository.

Caution - Sharing a single template repository for more than one application or library has not been, and is currently not, supported. Attempting to do so can lead to compilation failure and unpredictable results at runtime because of template redefinitions. See the C++ User's Guidefor more information.

6.1.5 Linking With 4.0.1 Libraries Containing Pointers to `const` Member Functions

The 4.0.1 C++ compiler generated different mangled names for pointers to const member functions than the 4.1, 4.2 and 5.0 through 5.7 versions of the C++ compiler. If you are using the C++ compiler and you are unable to link with a library that was built with 4.0.1 and that contains such names, you should either recompile the library, or compile the rest of the program with the -compat -Qoption ccfe -abirel=4.0.1 options.

Note - Future releases may not support the -abirel=4.0.1 option.

6.1.6 Linking With Libraries Compiled With Earlier Compilers

The C++ 4.0.1 and C++ 4.1 compilers generated a mangled name that was unparseable for templates instantiated with an extern "C" function. As a consequence, debugging tools behaved incorrectly. We have corrected the problem, but some users may be unable to link objects that are compiled using versions 5.0 through 5.7 of the C++ compiler with libraries compiled with earlier compilers. This incompatibility should be extremely rare, but in the event that it does happen, you can either do one of the following"

Recompile the library with the latest Sun C++ compiler

Compile the new objects using the latest Sun C++ compiler with the -compat and -Qoption ccfe -abirel=4.1 flags.

Note - Future releases may not support the -abirel=4.1 flag.

6.1.7 Mixing Object Code From Different Versions

You can mix object code from different versions of the C++ compiler in the same program, as long as you don't mix compatibility-mode and standard-mode code. However, you must link the final program using a compiler at least as new as the newest compiler version in the mix.

Note - You cannot link 4.2 and standard-mode C++ code together.