This section describes some aspects of compiling and linking programs. In the following example, CC is used to compile three source files and to link the object files to produce an executable file named prgrm.
demo% CC file1.cc file2.cc file3.cc -o prgrm
In the previous example, the compiler automatically generates the loader object files (file1.o, file2.o and file3.o) and then invokes the system linker to create the executable program for the file prgrm.
After compilation, the object files (file1.o, file2.o,and file3.o) remain. This convention permits you to easily relink and recompile your files.
If only one source file is compiled and a program is linked in the same operation, the corresponding .o file is deleted automatically. To preserve all .o files, do not compile and link in the same operation unless more than one source file gets compiled.
If the compilation fails, you will receive a message for each error. No .o files are generated for those source files with errors, and no executable program is written.
You can compile and link in separate steps. The -c option compiles source files and generates .o object files, but does not create an executable. Without the -c option, the compiler invokes the linker. By splitting the compile and link steps, a complete recompilation is not needed just to fix one file. The following example shows how to compile one file and link with others in separate steps:
demo% CC -c file1.cc Make new object file demo% CC -o prgrm file1.o file2.o file3.o Make executable file
Be sure that the link step lists all the object files needed to make the complete program. If any object files are missing from this step, the link will fail with "undefined external reference" errors (missing routines).
If you do compile and link in separate steps, consistent compiling and linking is critical when using the following compiler options:
-fast
-g
-g0
-library
-misalign
-mt
-p
-xa
-xarch=a
-xcg92 and -xcg89
-xpg
-xprofile
-xtarget=t
If you compile any subprogram with any of these options, be sure to link with the same option as well:
In the case of the -library, -fast, and -xarch options, you must be sure to include the linker options that would have been passed if you had compiled and linked together.
With -p, -xpg and -xprofile, including the option in one phase and leaving it out of the other will not affect the correctness of the program but you will not be able to do profiling.
With -g and -g0, including the option in one phase and leaving it out of the other will not affect the correctness of the program, but the program will not be prepared properly for debugging.
In the following example, the programs are compiled using the -xcg92 compiler option. This option is a macro for -xtarget=ss1000 and expands to: -xarch=v8 -xchip=super -xcache=16/64/4:1024/64/1
If the program uses templates, it is possible that some templates will get instantiated at link time. In that case the command line options from last line (the link line) will be used to compile the instantiated templates.
demo% CC -c -xcg92 sbr.cc demo% CC -c -xcg92 smain.cc demo% CC -xcg92 sbr.o smain.o
You can create both 32-bit and 64-bit binaries using the C++ 5.0 compiler.
Compilation, linking, and execution of 64-bit objects can take place only in a V9 SPARC, Solaris 7 environment with a 64-bit kernel running. Compilation for 64-bit Solaris 7 is indicated by the -xarch=v9 and -xarch=v9a options.
You can use the -verbose option to display helpful information while compiling a program. See Chapter 3, C++ Compiler Options for more information.
Any arguments on the command line that the compiler does not recognize are interpreted as linker options, object program file names, or library names.
The basic distinctions are:
Unrecognized options, preceded by a dash (-) or a plus sign (+) generate warnings.
Unrecognized nonoptions, not preceded by a dash or a plus sign, generate no warnings. (However, they are passed to the linker. If the linker does not recognize them, they generate linker error messages.)
In the following example, note that -bit is not recognized by CC and the option is passed on to the linker (ld), which tries to interpret it. Because single letter ld options can be strung together, the linker sees -bit as -b -i -t, all of which are legitimate ld options. This might not be what you intend or expect:
demo% CC -bit move.cc <- -bit is not a recognized CC option CC: Warning: Option -bit passed to ld, if ld is invoked, ignored otherwise
In the next example, the user intended to type the CC option -fast but omitted the leading dash. The compiler again passes the argument to the linker, which in turn interprets it as a file name:
demo% CC fast move.cc <- The user meant to type -fast move.C: ld: fatal: file fast: cannot open file; errno=2 ld: fatal: File processing errors. No output written to a.out
The C++ compiler package consists of a front end, optimizer, code generator, assembler, template pre-linker, and link editor. The CC command invokes each of these components automatically unless you use command-line options to specify otherwise.
Because any of these components may generate an error, and the components perform different tasks, it may be helpful to identify the component that generates an error.
As shown in the following table, input files to the various compiler components have different file name suffixes. The suffix establishes the kind of compilation that is done. Refer to Table 2-1 for the meanings of the file suffixes.
Table 2-2 Components of the C++ Compilation System
Component |
Description |
Notes on Use |
---|---|---|
ccfe |
Front end (Compiler preprocessor and compiler) | |
iropt |
Code optimizer |
(SPARC) -xO[2-5], -fast |
xcg386 |
Intermediate language translator |
(x86) Always invoked |
inline |
Inline expansion of assembly language templates |
(SPARC).il file specified |
mwinline |
Automatic inline expansion of functions |
(x86) -xO4, -xinline |
fbe |
Assembler |
|
cg |
Code generator, inliner, assembler |
(SPARC) |
codegen |
Code generator |
(x86) |
CClink |
Template pre-linker |
|
ld |
Non-incremental link editor |
|
ild |
Incremental link editor |
-g, -xildon |
The amount of memory a compilation requires depends on several parameters, including:
Size of each procedure
Level of optimization
Limits set for virtual memory
Size of the disk swap file
On the SPARC platform, if the optimizer runs out of memory, it tries to recover by retrying the current procedure at a lower level of optimization. The optimizer then resumes subsequent routines at the original level specified in the -xOlevel option on the command line.
If you compile a single source file that contains many routines, the compiler might run out of memory or swap space. If the compiler runs out of memory, try reducing the level of optimization. Alternately, split multiple-routine source files into files with one routine per file, using fsplit(1).
The swap -s command displays available swap space. See the swap(1M) man page for more information.
The following example demonstrates the use of the swap command:
demo% swap -s total: 40236k bytes allocated + 7280k reserved = 47516k used, 1058708k available
Use mkfile(1M) and swap (1M) to increase the size of the swap space on a workstation. (You must become superuser to do this.) The mkfile command creates a file of a specific size, and swap -a adds the file to the system swap space:
demo# mkfile -v 90m /home/swapfile /home/swapfile 94317840 bytes demo# /usr/sbin/swap -a /home/swapfile
Compiling very large routines (thousands of lines of code in a single procedure) at -xO3 or higher can require an unreasonable amount of memory. In such cases, performance of the system might degrade. You can control this by limiting the amount of virtual memory available to a single process.
To limit virtual memory in a sh shell, use the ulimit command. See the sh(1) man page for more information.
The following example shows how to limit virtual memory to 16 Mbytes:
demo$ ulimit -d 16000
In a csh shell, use the limit command to limit virtual memory. See the csh(1)man page for more information.
The next example also shows how to limit virtual memory to 16 Mbytes:
demo% limit datasize 16M
Each of these examples causes the optimizer to try to recover at 16 Mbytes of data space.
The limit on virtual memory cannot be greater than the system's total available swap space and, in practice, must be small enough to permit normal use of the system while a large compilation is in progress.
Be sure that no compilation consumes more than half the swap space.
With 32 Mbytes of swap space, use the following commands:
demo$ ulimit -d 16000
demo% limit datasize 16M
The best setting depends on the degree of optimization requested and the amount of real memory and virtual memory available.
A workstation should have at least 24 megabytes of memory; 32 megabytes are recommended.
To determine the actual real memory, use the following command:
demo% /usr/sbin/dmesg | grep mem mem = 655360K (0x28000000) avail mem = 602476544