The Single UNIX ® Specification, Version 2
Copyright © 1997 The Open Group

 NAME

cc - a C-language compilation system (LEGACY)

 SYNOPSIS



cc [-c][-C][-e epsym] [-D name[=value]]... [-E][-f][-F][-g]
[-I directory]... [-L directory]... [-o outfile][-O][-p][-P]
[-q][-r][-s][-S][-u symname]... [-U name]... [-W options]... operand...

 DESCRIPTION

The cc utility is an interface to an unspecified C-language compilation system. The system conceptually consists of a preprocessor, compiler, optimiser, assembler and link editor. The cc utility processes the supplied options and then executes the various tools with the appropriate arguments.

The suffix of the pathname versions of an operand indicates how it is to be treated. See the OPERANDS section.

The files referenced by operands will be compiled/assembled and linked to produce an executable file. (It is unspecified whether the linking occurs entirely within the operation of cc; some systems may produce objects that are not fully resolved until the file is executed.)

If the -c option is specified, for all pathname operands of the form file.c the files:


$(basename pathname .c).o

will be created as the result of successful compilation. Similar results occur for pathname operands of the form file.i and .s. If the -c option is not specified, it is unspecified whether such .o files are created or deleted for these operands.

If there are no options that prevent link editing (such as -c or -E), and all operands compile and link without error, the resulting executable file will be written according to the -o outfile option (if present) or to the file a.out.

The executable file will be created as specified in the XSH specification, except that the file permissions will be set to:

S_IRWXO | S_IRWXG | S_IRWXU
and that the bits specified by the umask of the process will be cleared.

 OPTIONS

The cc utility supports the XBD specification, Utility Syntax Guidelines  , except that:

The following options are supported:

-c
Suppress the link-edit phase of the compilation, and do not remove any object files that are produced.
-E
Run only the preprocessor on the named C-language programs and send the result to standard output.
-f
Include floating-point support for systems without an automatically included floating point implementation. This option is ignored on systems that do not need it.
-F
This option is reserved for implementation-dependent optimisation directives.
-g
Cause the compiler to generate additional information needed for use by a debugger (possibly sdb).
-o outfile
Use the name outfile instead of the default a.out for the executable file produced. This is a link-edit option.
-O
Do compilation phase optimisation. This option will not affect .s files.
-p
This option is reserved for invoking implementation-dependent profiling procedures.
-P
Run only the preprocessor on the named C-language programs and leave the result on corresponding files suffixed .i.
-q
This option is reserved for specifying implementation-dependent profiling directives.
-S
Compile and do not assemble the named C-language programs, and leave the assembler-language output on corresponding files suffixed .s.
-W c,arg[,arg ...]
Pass the arguments arg to phase c where c is one of [p02al] indicating preprocessing, compiling, optimising, assembling or link editing phases, respectively. For example, -Wa,-m passes -m to the assembler phase.

The cc utility also recognises a number of options that it will pass (with their associated arguments) directly to another phase of the cc utility. The use of the -W option is not required for these options.

The following options are passed by cc (with their associated arguments) to the preprocessor phase:

-C
By default, the preprocessor strips C-language style comments. If the -C option is specified, all comments (except those found on preprocessor directive lines) are passed along.
-D name[=value]
Define name as if by a C-language #define directive. If no =value is given, a value of 1 will be used. The -D option has lower precedence than the -U option. That is, if name is used in both a -U and a -D option, name will be undefined regardless of the order of the options. Additional implementation-dependent names may be provided by the compiler. Implementations support at least 2048 bytes of -D definitions and 256 names.
-I directory
Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose names are enclosed in double-quotes ("") will be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets (<>), the header will be searched for only in directories named in -I options and then in the usual places. Directories named in -I options will be searched in the order specified. Implementations support at least ten instances of this option in a single cc command invocation.
-U name
Remove any initial definition of name, where name is a reserved symbol that is predefined by the particular preprocessor.

The following options are passed by cc (with their associated arguments) to the link-edit phase:

-e epsym
Set the default entry point address for the output file to be that of the symbol epsym.
-L dir
Change the algorithm of searching for the libraries named in the -l objects to look in the directory named by the directory pathname before looking in the usual places. Directories named in -L options will be searched in the order specified. Implementations support at least ten instances of this option in a single cc command invocation. If a directory specified by a -L option contains files named libc.a, libm.a, libl.a, or liby.a, the results are unspecified. This option is only effective if it precedes the -l option on the command line.
-r
Retain relocation entries in the output object file. Relocation entries must be saved if the output is to become the input of a subsequent cc run. The link-edit phase will not complain about unresolved references and will not make the object output executable.
-s
Produce object or executable files, or both, from which symbolic and other information not required for proper execution using the XSH specification exec family has been removed (stripped). If both -g and -s options are present, the action taken is unspecified.
-u symname
Enter symname as an undefined symbol into the symbol table. This is useful for loading entirely from a library, since initially the symbol table is empty and an unresolved reference is needed to force loading of the first routine.

 OPERANDS

An operand is either in the form of a pathname or the form -l library. At least one operand of the pathname form must be specified. The following operands are supported:
file.c
A C-language source file that may be preprocessed, compiled, optimised and link edited.
file.i
A C-language source file that has been preprocessed, and may be compiled, optimised and link edited.
file.s
An assembly language source file that may be assembled and link edited.
file.a
A library of object files typically produced by the ar utility, and passed directly to the link editor.

The operand must be one of the forms file.c file.i or file.s if the -c option is used.

-l library
(The letter ell.) Search the library named:

liblibrary.a

A library will be searched when its name is encountered, so the placement of a -l operand is significant. Several standard libraries can be specified in this manner, as described in the EXTENDED DESCRIPTION section.

Other arguments are taken to be C-language compatible object programs, typically produced by an earlier cc run, or perhaps libraries of C-language compatible routines, and are passed directly to the link editor. These programs, together with the results of any compilations specified, are linked (in the order given) to produce an executable program with the name a.out (unless the -o link-edit option is used).

The standard C-language library is automatically available to the C-language program. Other libraries may be specified explicitly using the -l option with cc.

 STDIN

Not used.

 INPUT FILES

The input file will be one of the following: a text file containing a C-language source program; a text file containing an (implementation-dependent) assembly-language source program; an object file in the format produced by cc -c or a library of object files, in the format produced by archiving zero or more object files, using ar. Additional input file formats are implementation-dependent.

 ENVIRONMENT VARIABLES

The following environment variable affects the execution of cc:
TMPDIR
Provide a pathname that will override the default directory for temporary files, if any.

The following environment variables may affect the execution of cc:

LANG
Provide a default value for the internationalisation variables that are unset or null. If LANG is unset or null, the corresponding value from the implementation-dependent default locale will be used. If any of the internationalisation variables contains an invalid setting, the utility will behave as if none of the variables had been defined.
LC_ALL
If set to a non-empty string value, override the values of all the other internationalisation variables.
LC_CTYPE
Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters in arguments and input files).
LC_MESSAGES
Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.
NLSPATH
Determine the location of message catalogues for the processing of LC_MESSAGES .

 ASYNCHRONOUS EVENTS

Default.

 STDOUT

If more than one file operand ending in .c, .i or .s is given, for each such file:

"%s:\n", <file> may be written. These messages, if written, will precede the processing of each input file; they will not be written to standard output if they are written to standard error, as described in the STDERR section.

If the -E option is specified, the standard output will be a text file that represents the results of the preprocessing stage of the language; it may contain extra information appropriate for subsequent compilation passes.

 STDERR

Used only for diagnostic messages. If more than one file operand ending in .c (or possibly other unspecified suffixes) is given, for each such file:

"%s:\n", <file> may be written to allow identification of the diagnostic and warning messages with the appropriate input file. These messages, if written, will precede the processing of each input file; they will not be written to standard error if they are written to standard output, as described in the STDOUT section.

This utility may produce warning messages about certain conditions that do not warrant returning an error (non-zero) exit value.

 OUTPUT FILES

If the -P option is specified, text files are created that represent the results of the preprocessing stage of the language.

Object files or executable files or both are produced in unspecified formats.

 EXTENDED DESCRIPTION

All implementations will support standard libraries as described in c89, EXTENDED DESCRIPTION.
 External Symbols
The C compiler and link editor support the significance of external symbols up to a length of at least 31 bytes; the action taken upon encountering symbols exceeding the implementation-dependent maximum symbol length is unspecified.

The compiler and link editor support a minimum of 511 external symbols per source or object file, and a minimum of 4095 external symbols total. A diagnostic message will be written to the standard error if the implementation-dependent limit is exceeded; other actions are unspecified.

 Programming Environment

All implementations will support one or more programming environments with cc as specified in c89, EXTENDED DESCRIPTION.

 EXIT STATUS

The following exit values are returned:
0
Successful compilation or link edit.
>0
An error occurred.

 CONSEQUENCES OF ERRORS

When cc encounters a compilation error that causes an object file not to be created, it will write a diagnostic to standard error and continue to compile other source code operands, but it will not perform the link phase and will return a non-zero exit status. If the link edit is unsuccessful, a diagnostic message will be written to standard error and cc will exit with a non-zero status. A portable application must rely on the exit status of cc, rather than on the existence or mode of the executable file.

 APPLICATION USAGE

The c89 utility provides an interface to the ISO C standard, but the cc utility accepts an unspecified dialect of the C language: it may be Standard C, common-usage C or some other variant. Portable C programs should be written to conform to the ISO C standard and compiled with c89.

Since the cc utility usually creates files in the current directory during the compilation process, it is typically necessary to run the cc utility in a directory in which a file can be created.

Some historical implementations have created .o files when -c is not specified and more than one source file is given. Since this area is left unspecified, the application cannot rely on .o files being created, but it also must be prepared for any related .o files that already exist being deleted at the completion of the link edit.

Some historical implementations have permitted -L options to be interspersed with -l operands on the command line. For an application to compile consistently on systems that do not behave like this, it is necessary for a portable application to supply all -L options before any of the -l options.

There is the possible implication that if a user supplies versions of the standard library functions (before they would be encountered by an implicit -l c or explicit -l m), that those versions would be used in place of the standard versions. There are various reasons this might not be true (functions defined as macros, manipulations for clean name space, and so on), so the existence of files named in the same manner as the standard libraries within the -L directories is explicitly stated to produce unspecified behaviour.

All of the interfaces specified in the XSH specification may be made visible by implementations when the Standard C Library is searched. Portable applications must explicitly request searching the other standard libraries when functions made visible by those libraries are used.

Applications should migrate to the c89 utility.

 EXAMPLES

The following are examples of usage:
cc -o foo foo.c bar.s
Compiles foo.c, assembles bar.s and creates the executable file foo.
cc -c foo.c
Compiles foo.c and creates the object file foo.o.
cc foo.c
Compiles foo.c and creates the executable file a.out.
cc foo.c bar.o
Compiles foo.c, links it with bar.o, and creates the executable a.out. Also creates and leaves foo.o.

The following examples clarify the use and interactions of -L options and -l operands:

  1. Consider the case in which module a.c calls function f() in library libQ.a, and module b.c calls function g() in library libp.a. Assume that both libraries reside in /a/b/c. The command line to compile and link in the desired way is:
    
    cc -L /a/b/c main.o a.c -l Q b.c -l p
    
    
    In this case the -l Q operand need only precede the first -l p operand, since both libQ.a and libp.a reside in the same directory.

  2. Multiple -L operands can be used when library name collisions occur. Building on the previous example, suppose that the user now wants to use a new libpa., in /a/a/a, but still wants f() from /a/b/c/libQ.a:
    
    cc -L /a/a/a -L /a/b/c main.o a.c -l Q b.c -l p
    
    

    In this example, the linker searches the -L options in the order specified, and finds /a/a/a/libp.a before /a/b/c/libp.a when resolving references for b.c. The order of the -l operands is still important, however.

 FUTURE DIRECTIONS

None.

 SEE ALSO

ar, c89, nm, strip.

UNIX ® is a registered Trademark of The Open Group.
Copyright © 1997 The Open Group
[ Main Index | XSH | XCU | XBD | XCURSES | XNS ]