DLL Programmer's Guide for TNS/E Systems

Essential DLL Facility Controls
DLL Programmer’s Guide for TNS/E Systems—527252-006
2-21
C++ Dialect
Checking the C++ Dialect of Linkfiles That Go into a Link
The linker checks for consistency of C++ dialect among all input linkfiles. If any linkfiles
from C++ compilations differ in C++ dialect, the linker terminates in error.
Setting the C++ Dialect of a Loadfile Being Linked
The C++ dialect of the loadfile being linked is determined in one of two ways.
1. If the -set cppdialect cppneutral option is specified, the linker sets the
output loadfile C++ dialect to neutral. See Neutralizing the C++ Dialect of a
Loadfile on page 2-21.
2. Otherwise, if all C++ compilation units among the input linkfiles have the same
dialect, the linker sets the output loadfile's cppdialect attribute to that value.
Checking the C++ Dialect of Loadfiles in a Process
The loader checks the consistency of C++ dialect in all the native loadfiles in the
process. For PIC processes, there are two assertions:

No loadfile has cppdialect = version1. Violation results in process creation error 78
(operation not supported) with error-detail 6 (C++ version1 is not supported).

All loadfiles that have non-neutral cppdialect have the same value, version2 or
version3. Violation results in process creation error 77 (unable to load object file)
with error-detail 8 (mixed C++ dialect versions are not allowed).
The checking applies to all loadfiles: the program, DLLs, and public DLLs. It applies to
libraries dynamically loaded by dlopen()as well as those loaded at process creation
time. Violation of either assertion generates a unique process-creation error, detail
(78,6 and 77,8, respectively; see the Guardian Procedure Errors and Messages
Manual).
Neutralizing the C++ Dialect of a Loadfile
The linker can overwrite the cppdialect attribute of an existing PIC loadfile; the
command is:
eld -change cppdialect cppneutral filename
This action must be taken with care. Like the corresponding -set option at link time, it
causes the presence of any C++ code in this loadfile to be suppressed. Neutralization
can be useful for a library that happens to contain code compiled by C++ but does not
have any dependencies on C++ run-time libraries, and does not import or export any
C++ objects or compiler-generated identifiers. The neutralized library can load into the
same process as other loadfiles with a different version of C++. But if applied
improperly, this assertion of neutrality can lead to errors ranging from fairly obvious
(such as unresolved symbols) to rather subtle (such as differing semantics in different
versions of same-named support-library functions).