cc.html

unix 下的C开发手册,还用详细的例程。

The operand must be one of the forms
<i>file</i>.c
<i>file</i>.i
or
<i>file</i>.s
if the
<b>-c</b>
option is used.
<dl compact>

<dt><b>-l&nbsp;</b><i>library</i>
<dd>
(The letter ell.)
Search the library named:
<pre>
<code>
lib<i>library</i>.a
</code>
</pre>

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

</dl>
<p>
Other arguments are taken to be C-language compatible
object programs, typically produced by an earlier
<i>cc</i>
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
<b>a.out</b>
(unless the
<b>-o</b>
link-edit option is used).
<p>
The standard C-language library is automatically available to the
C-language program.
Other libraries may be specified
explicitly using the
<b>-l</b>
option with
<i>cc</i>.
</blockquote><h4><a name = "tag_000_000_291">&nbsp;</a>STDIN</h4><blockquote>
Not used.
</blockquote><h4><a name = "tag_000_000_292">&nbsp;</a>INPUT FILES</h4><blockquote>
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
<i>cc</i>
<b>-c</b>
or a library of object files, in the format produced by
archiving zero or more object files, using
<i><a href="ar.html">ar</a></i>.
Additional input file formats are implementation-dependent.
</blockquote><h4><a name = "tag_000_000_293">&nbsp;</a>ENVIRONMENT VARIABLES</h4><blockquote>
The following environment variable affects the execution of
<i>cc</i>:
<dl compact>

<dt><i>TMPDIR</i><dd>
Provide a pathname that
will override
the default directory for temporary files, if any.

</dl>
<p>
The following environment variables may affect the execution of
<i>cc</i>:
<dl compact>

<dt><i>LANG</i><dd>Provide a default value for the internationalisation variables
that are unset or null.
If
<i>LANG</i>
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.

<dt><i>LC_ALL</i><dd>
If set to a non-empty string value,
override the values of all the other internationalisation variables.

<dt><i>LC_CTYPE</i><dd>
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).

<dt><i>LC_MESSAGES</i><dd>
Determine the locale that should be used to affect
the format and contents of diagnostic
messages written to standard error.

<dt><i>NLSPATH</i><dd>
Determine the location of message catalogues
for the processing of
<i>LC_MESSAGES .
</i>
</dl>
</blockquote><h4><a name = "tag_000_000_294">&nbsp;</a>ASYNCHRONOUS EVENTS</h4><blockquote>
Default.
</blockquote><h4><a name = "tag_000_000_295">&nbsp;</a>STDOUT</h4><blockquote>
If more than one file operand ending in
.c,
.i
or
.s
is given, for each such file:
<p><code>
<tt>"%s:\n"</tt>, &lt;<i>file</i>&gt;
</code>
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.
<p>
If the
<b>-E</b>
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.
</blockquote><h4><a name = "tag_000_000_296">&nbsp;</a>STDERR</h4><blockquote>
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:
<p><code>
<tt>"%s:\n"</tt>, &lt;<i>file</i>&gt;
</code>
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.
<p>
This utility may produce warning messages about certain
conditions that do not warrant returning an error (non-zero)
exit value.
</blockquote><h4><a name = "tag_000_000_297">&nbsp;</a>OUTPUT FILES</h4><blockquote>
If the
<b>-P</b>
option is specified, text files are created
that represent the results of the preprocessing stage of the language.
<p>
Object files or executable files or both are produced in unspecified formats.
</blockquote><h4><a name = "tag_000_000_298">&nbsp;</a>EXTENDED DESCRIPTION</h4><blockquote>
All implementations will support standard libraries as described in
<i><a href="c89.html">c89</a></i>,
EXTENDED DESCRIPTION.
<h5><a name = "tag_000_000_298_001">&nbsp;</a>External Symbols</h5>
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.
<p>
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.
<h5><a name = "tag_000_000_298_002">&nbsp;</a>Programming Environment</h5>
<p>
All implementations will support one or more programming environments
with
<i>cc</i>
as specified in
<i><a href="c89.html">c89</a></i>,
EXTENDED DESCRIPTION.
</blockquote><h4><a name = "tag_000_000_299">&nbsp;</a>EXIT STATUS</h4><blockquote>
The following exit values are returned:
<dl compact>

<dt>0<dd>Successful compilation or link edit.

<dt>&gt;0<dd>An error occurred.

</dl>
</blockquote><h4><a name = "tag_000_000_300">&nbsp;</a>CONSEQUENCES OF ERRORS</h4><blockquote>
When
<i>cc</i>
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
<i>cc</i>
will exit with a non-zero status.
A portable application must rely on the exit status of
<i>cc</i>,
rather than on the existence or mode of the executable file.
</blockquote><h4><a name = "tag_000_000_301">&nbsp;</a>APPLICATION USAGE</h4><blockquote>
The
<i><a href="c89.html">c89</a></i>
utility provides an interface to the ISO&nbsp;C standard,
but the
<i>cc</i>
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&nbsp;C standard
and compiled with
<i><a href="c89.html">c89</a></i>.
<p>
Since the
<i>cc</i>
utility
usually creates files in the current
directory during the compilation process, it is typically
necessary to run the
<i>cc</i>
utility
in a directory in which a file can be created.
<p>
Some historical implementations have created
.o
files when
<b>-c</b>
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.
<p>
Some historical implementations have permitted
<b>-L</b>
options to be interspersed with
<b>-l</b>
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
<b>-L</b>
options before
any of the
<b>-l</b>
options.
<p>
There is the possible implication that if a user supplies versions
of the standard library functions (before they would be encountered
by an implicit
<b>-l c</b>
or explicit
<b>-l m</b>),
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
<b>-L</b>
directories is explicitly stated to produce unspecified behaviour.
<p>
All of the interfaces specified in the <b>XSH</b> 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.
<p>
Applications should migrate to the
<i><a href="c89.html">c89</a></i>
utility.
</blockquote><h4><a name = "tag_000_000_302">&nbsp;</a>EXAMPLES</h4><blockquote>
The following are examples of usage:
<dl compact>

<dt>cc -o foo foo.c bar.s<dd>
Compiles
<b>foo.c</b>,
assembles bar.s
and creates the executable file
<b>foo</b>.

<dt>cc -c foo.c<dd>
Compiles
<b>foo.c</b>
and creates the object file
<b>foo.o</b>.

<dt>cc foo.c<dd>
Compiles
<b>foo.c</b>
and creates the executable file
<b>a.out</b>.

<dt>cc foo.c bar.o<dd>
Compiles
<b>foo.c</b>,
links it with
<b>bar.o</b>,
and creates the
executable
<b>a.out</b>.
Also creates and leaves
<b>foo.o</b>.

</dl>
<p>
The following examples clarify the use and interactions of
<b>-L</b>
options and
<b>-l</b>
operands:
<ol>
<p>
<li>
Consider the case in which module
<b>a.c</b>
calls function
<i>f()</i>
in library
<b>libQ.a</b>,
and module
<b>b.c</b>
calls function
<i>g()</i>
in library
<b>libp.a</b>.
Assume that both libraries reside in
<b>/a/b/c</b>.
The command
line to compile and link in the desired way is:
<pre>
<code>
cc -L /a/b/c main.o a.c -l Q b.c -l p
</code>
</pre>
In this case the
<b>-l Q</b>
operand need only precede the first
<b>-l p</b>
operand, since both
<b>libQ.a</b>
and
<b>libp.a</b>
reside in the same directory.
<p>
<li>
Multiple
<b>-L</b>
operands can be used when library name collisions occur.
Building on the previous example,
suppose that the user now wants to use
a new
<b>libpa.</b>,
in
<b>/a/a/a</b>,
but still wants
<i>f()</i>
from
<b>/a/b/c/libQ.a</b>:
<pre>
<code>
cc -L /a/a/a -L /a/b/c main.o a.c -l Q b.c -l p
</code>
</pre>
<p>
In this example,
the linker searches the
<b>-L</b>
options in the order specified,
and finds
<b>/a/a/a/libp.a</b>
before
<b>/a/b/c/libp.a</b>
when resolving references for
<b>b.c</b>.
The order of the
<b>-l</b>
operands is still important, however.
<p>
</ol>
</blockquote><h4><a name = "tag_000_000_303">&nbsp;</a>FUTURE DIRECTIONS</h4><blockquote>
None.
</blockquote><h4><a name = "tag_000_000_304">&nbsp;</a>SEE ALSO</h4><blockquote>
<i><a href="ar.html">ar</a></i>,
<i><a href="c89.html">c89</a></i>,
<i><a href="nm.html">nm</a></i>,
<i><a href="strip.html">strip</a></i>.
</blockquote><hr size=2 noshade>
<center><font size=2>
UNIX &reg; is a registered Trademark of The Open Group.<br>
Copyright &copy; 1997 The Open Group
<br> [ <a href="../index.html">Main Index</a> | <a href="../xshix.html">XSH</a> | <a href="../xcuix.html">XCU</a> | <a href="../xbdix.html">XBD</a> | <a href="../cursesix.html">XCURSES</a> | <a href="../xnsix.html">XNS</a> ]

</font></center><hr size=2 noshade>
</body></html>