This chapter discusses C++ compiling and linking for the MIPSpro compilers. It contains the following sections:
“The C++ Command Line”, discusses the syntax of the C++ command and the options used with that command.
“Compiling and Linking”, describes the SGI C++ compilation process.
“Object File Tools”, briefly summarizes the capabilities of the tools that provide symbol and other information on object files.
This section provides an overview of the CC (1) command. For complete details about each option, see the CC man page.
The CC command invokes the compiler. The following syntax box shows the complete CC command syntax (note that cc command syntax is not indicated here).
CC [-64|-n32] [-all] [-anach] [-ansiE] [-ansiW] [-apo] [-apokeep] [-apolist] [-ar] [-auto_include] [-bigp_off] [-bigp_on] [-brief_diagnostics] [-c] [-cfront] [-common] [-D name=def] [-DEBUG] [-diag_error numberlist] [-diag_remark numberlist] [-diag_suppress numberlist] [-diag_warning numberlist] [-dollar] [-E] [-fb file] [-fb_create path] [-fb_opt path] [-fbgen] [-fbuse file] [-FE:eliminate_duplicate_inline_copies] [-FE:template_in_elf_section] [-float] [-float_const][-fullwarn] [-G num] [-g[n]] [-gslim] [-help] [-I dir] [-ignore_suffix] [-INLINE] [-IPA] [-J #] [-KPIC] [-L directory] [-l library] [-LANG] [-LIST] [-LNO] [-M] [-MDupdate filename] [-mipsn] [-MP] [-mp] [-mplist] [-no_auto_include] [-noinline] [-non_shared] [-no_prelink] [-none] [-nostinc] [-o outfile] [-O[n]] [-Ofast [= ipxx]] [-OPT:] [-P] [-pch] [-pedantic] [-prelink] [-pta] [-ptall] [-ptnone] [-ptused] [-ptv] [-quiet_prelinker] [-r] [-rprocessor] [-S] [-shared] [-show] [-signed] [-TARG] [-TENV] [-trapuv] [-U name] [-use_command] [-use_readonly_const] [-use_readwrite_const] [-use_suffix] [-v] [-version] [-W c,arg1 [,arg2...]] [-w] [-w2] [-woff all] [-woff numberlist] [-x lang] [-Xcpluscomm] [-Y c,path] files |
In some cases, more than one option can have an effect on a single compiler feature. The following list shows some of the compiler features and the options that affect them:
Source preprocessing: -Dvar[ =def][,var[ =def]]..., -E, -nocpp, -P, -Uname.
Setting the compilation environment: -n32, -64, -mipsn, -rprocessor, -TARG:, -TENV:.
Optimization: -apo, -LNO:, -OPT:, -Olevel.
 | Note: In order to use the APO command line options, you must be licensed for the MIPSpro Auto-Parallelizing Option. |
Various environment variable settings can affect your compilation. For more information on the environment variables, see the pe_environ(5) man page.
Some CC(1) command options, for example, -LNO:..., -LIST:..., -MP:... , -OPT:..., -TARG:..., and -TENV:... accept several suboptions and allow you to specify a setting for each suboption. To specify multiple suboptions, either use colons to separate each suboption or specify multiple options on the command line. For example, the following command lines are equivalent:
% CC -LIST:notes=ON:options=OFF b.c % CC -LIST:notes=ON -LIST:options=OFF b.c |
Some arguments to suboptions of this type are specified with a setting that either enables or disables the feature. To enable a feature, specify the suboption either alone or with =1, =ON, or =TRUE. To disable a feature, specify the suboption with either =0, =OFF, or =FALSE . For example, the following command lines are equivalent:
% CC -LNO:auto_dist:blocking=OFF:oinvar=FALSE a.c % CC -LNO:auto_dist=1:blocking=0:oinvar=OFF a.c |
For brevity, this manual shows only the ON or OFF settings to suboptions, but the compiler also accepts 0, 1, TRUE, and FALSE as settings.
The following list summarizes the options to the CC command. For complete details, see the CC(1) man page.
The two compilation processes in Figure 2-1, show what transformations a C++ source file, foo.C, undergoes with the N32, 64, and O32 compilers. The MIPSpro compilation process is on the left, invoked by specifying either -n32 or -64 mode, as shown in the following examples:
CC -n32 -o foo foo.C |
CC -64 -o foo foo.C |
On the right is the O32 compilation process, invoked by using -o32, as shown in the following example:
CC -o32 -o foo foo.C |
The following steps further describe the compilation stages in Figure 2-1:
You invoke CC on the source file, which has the suffix .C. The other acceptable suffixes are .c++, .c, .cc, .cpp, .CPP, .cxx, or .CXX.
The source file passes through the C++ preprocessor, which is built into the C++ compiler.
The complete source is processed using a syntactic and semantic analysis of the source to produce an intermediate representation.
This stage may also produce a prelink (.ii) file, which contains information about template instantiations.
Optimized object code (foo.o) is then generated.
This command produces object code, foo.o, that is suitable for later linking.
The compiler processes the .ii files associated with the objects that will be linked together. Then sources are recompiled to force template instantiation.
The object files are sent to the linker, ld (see the ld(1) man page), which links the standard C++ library libC.so and the standard C library libc.so to the object file foo.o and to any other object files that are needed to produce the executable.
In -o32 mode, the executable object is sent to c++patch, which links it with global constructors and destructors. If global objects with constructors or destructors are present, the constructors need to be called at run time before function main() , and the destructors need to be called when the program exits. c++patch modifies the executable, a.out, to ensure that these constructors and destructors get called.
The following are some typical C++ compiler command lines:
To compile one program and suppress the loading phase of your compilation, use the following command line:
CC -c program
To compile with full warnings about questionable constructs, use the following command line:
CC -fullwarn program1 program2 ...
To compile with warning messages off, use the following command line:
CC -w program1 program2 ...
C++ programs can be compiled and linked with programs written in other languages, such as C, Fortran, and Pascal. When your application has two or more source programs written in different languages, you should do the following:
Compile each program module separately with the appropriate compiler.
Link them together in a separate step.
You can create objects suitable for linking by specifying the -c option. For example:
CC -c main.c++ f77 -c module1.f cc -c module2.c |
The three compilers produce three object files: main.o, module1.o, and module2.o. Since the main module is written in C++, you should use the CC command to link. In fact, if any object file is generated by C++, it is best to use CC to link. Except for C, you must explicitly specify the link libraries for the other languages with the -l option. For example, to link the C++ main module with the Fortran submodule, use the following command line:
CC -o almostall main.o module1.o -lftn -lm |
For more information on C++ libraries, see “C++ Libraries” in Chapter 1.
Diagnostic messages can be issued from the C++ front end, the language-independent back end, or the linker.
The front end issues errors, warnings , and remarks. The following examples demonstrate these types of messages.
Example 2-1. Compiler front end ERROR message
The following code fragment produces an error message when compiled with the command shown:
void foo()
{
x=1;
}
% CC -c ex1.cxx |
The following error message is displayed:
cc-1020 CC: ERROR File=ex1.cxx, Line=3 The identifier "x" is undefined. x = 1; ^ |
Example 2-2. Compiler front end WARNING message
The following code fragment produces a warning message when compiled with the command shown:
int foo(int x)
{
if (x==1) return 0;
}
% CC -c ex2.cxx |
The following warning message is displayed:
cc-3604 CC: WARNING File = ex2.cxx, Line = 4 missing return statement at end of non-void function "foo" } ^ |
Example 2-3. Compiler front end Remark
The following code fragment produces a remark when compiled with the command shown:
class C {};
class D {
friend C;
};
% CC -c -fullwarn ex3.cxx |
The following remark is displayed:
Omission of "class" is nonstandard
friend C;
^ |
Remarks occur only if the -fullwarn option is specified or if their severity is adjusted, as described in “Adjusting the Severity of Messages”.
Programs with only warnings and remarks will compile; programs with errors will not.
For some diagnostic messages, explanatory information is available by using the explain(1) command. In Example 2-1, the following explanation is provided when the explain command shown is used:
% explain cc-1020 The identifier %sq is undefined. The identifier "name" does not appear in a declaration. Check your declarations and the headers you have included to make sure the identifier is included. If it is a user defined type or function, it must be declared before it can be used. |
Diagnostics from the back end seldom occur.
Diagnostics from the linker are common and are usually clear. Linker messages do not have numbers and the explain command cannot be used. One class of linker error is specific to C++ and may be confusing, as the following example demonstrates.
Compiling the following fragment with the indicated command line produces the resulting error:
class Base
{
public:
virtual void Action ( void );
};
class Derived : public Base
{
public:
void Action( void );
};
int main( int ncmds, char *cmds[] )
{
Derived *it = new Derived;
it->Action();
}
void Derived::Action( void )
{
}
|
% CC ex5.cxx |
ld32: ERROR 33 : Unresolved data symbol "Base::_vtbl" -- 1st referenced by ex5.o. Use linker option -v to see when and which objects, archives, and dsos are loaded. ld32: ERROR 33 : Unresolved data symbol "__T_4Base" -- 1st referenced by ex5.o. Use linker option -v to see when and which objects, archives, and dsos are loaded. |
In this example, the unresolved symbols are hard to correlate to anything in the user program. Base::__vtbl refers to the virtual table for the class Base. Virtual tables are an implementation mechanism for virtual functions. They are data and they need to be in the executable. To avoid duplicating the virtual table for a class in every object file containing the class declaration, the compiler places the virtual table in the class that contains the definition of the first non-inline virtual function in the class.
In the example, the first such function in the class Base is Action, and it is not defined anywhere. This problem cannot be detected until link time, and it results in the first diagnostic above. The second diagnostic is related and never appears in the absence of the __vtbl message.
If you encounter such a message, look for the first non-inline virtual function in the indicated class and make sure that it is defined somewhere.
Users can adjust the severity of diagnostic messages by using the -diag_error, -diag_warning, and -diag_remark options to the compiler. For example, if you do not want a program to compile if there is a missing return statement, use the -diag_error 3604 option. Compiling Example 2-2, with the command shown below produces the following error:
% CC -c -diag_error 3604 ex3.cxx cc-3604 CC: ERROR File = ex2.cxx, Line = 4 missing return statement at end of non-void function "foo" } ^ |
To avoid producing even warnings for this example, use either the -woff 3604 or -diag_remark 3604 options.
To see a warning for Example 2-3, without compiling with the -fullwarn option, use the -diag_remark 3604 option.
It is sometimes possible to reduce an error to a warning or to a remark. These errors are discretionary errors. The error in Example 2-1, is not discretionary, so if -diag_warning 1020 is specified, the error still occurs. If -diag_warning 1238 is used, the error in the following example is reduced to a warning:
class C {
int data;
public:
C(): data(1) {}
};
int main ()
{
C c;
return c.data;
}
cc-1238: ERROR File = ex4.cxx, Line = 10
The member "C::data" is inaccessible.
return c.data;
^ |
The following object file tools are of special interest to the C++ programmer:
nm: this tool can print symbol table information for object and archive files.
c++filt: this tool, specifically for C++, translates the internally coded (mangled) names generated by the C++ translator into names more easily recognized by the programmer. You can pipe the output of stdump or nm into c++filt, which is installed in the /usr/lib/c++ directory. For example:
nm a.out | /usr/lib/c++/c++filt
libmangle.a: the /usr/lib/c++/libmangle.a library provides a demangle(char *) function that you can invoke from your program to output a readable form of a mangled name. This is useful for writing your own tool for processing the output of nm, for example. You must declare the following in your program, and link with the library using the -lmangle option:
char * demangle(char *);
size: the size tool prints information about the text, rdata, data, sdata, bss, and sbss sections of the specific object or archive file.
elfdump: the elfdump tool lists the contents of an ELF (Executable and Linking Format) object file, including the symbol table and header information. See the elfdump(1) man page for more information.
stdump: the stdump tool outputs a file of intermediate-code symbolic information to standard output for O32 executables only. See the stdump(1) man page for more information.
dwarfdump: the dwarfdump tool outputs a file of intermediate-code symbolic information to standard output for -n32 and -64 compilations. See the dwarfdump(1) man page for more information.
For more complete information on the object file tools, see the MIPSpro N32/64 Compiling and Performance Tuning Guide.