Originální popis anglicky:
c99 - compile standard C programs
Návod, kniha: POSIX Programmer's Manual
c99 [-c][-D
name[=value
]]...[-E][-g][-I
directory ] ... [-L
directory]
...
[-o
outfile][
-Ooptlevel][-s][-U
name]...
operand ...
The
c99 utility is an interface to the standard C compilation system; it
shall accept source code conforming to the ISO C standard. The system
conceptually consists of a compiler and link editor. The files referenced by
operands shall be compiled and linked to produce an executable file.
(It is unspecified whether the linking occurs entirely within the operation of
c99; some implementations 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
shall be created as the result of successful compilation. If the
-c
option is not specified, it is unspecified whether such
.o files are
created or deleted for the
file .c 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 shall be written according to the
-o outfile
option (if present) or to the file
a.out.
The executable file shall be created as specified in
File Read, Write,
and Creation , except that the file permission bits shall be set
to:
S_IRWXO | S_IRWXG | S_IRWXU
and the bits specified by the
umask of the process shall be cleared.
The
c99 utility shall conform to the Base Definitions volume of
IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines,
except that:
- *
- The -l library operands have the format of
options, but their position within a list of operands affects the order in
which libraries are searched.
- *
- The order of specifying the -I and -L options
is significant.
- *
- Conforming applications shall specify each option
separately; that is, grouping option letters (for example, -cO)
need not be recognized by all implementations.
The following options shall be supported:
- -c
- Suppress the link-edit phase of the compilation, and do not
remove any object files that are produced.
- -g
- Produce symbolic information in the object or executable
files; the nature of this information is unspecified, and may be modified
by implementation-defined interactions with other options.
- -s
- Produce object or executable files, or both, from which
symbolic and other information not required for proper execution using the
exec family defined in the System Interfaces volume of
IEEE Std 1003.1-2001 has been removed (stripped). If both
-g and -s options are present, the action taken is
unspecified.
- -o outfile
- Use the pathname outfile, instead of the default
a.out, for the executable file produced. If the -o option is
present with -c or -E, the result is unspecified.
- -D
name[=value]
-
Define name as if by a C-language #define directive. If no =
value is given, a value of 1 shall 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 shall be
undefined regardless of the order of the options. Additional
implementation-defined names may be provided by the compiler.
Implementations shall support at least 2048 bytes of -D definitions
and 256 names.
- -E
- Copy C-language source files to standard output, expanding
all preprocessor directives; no compilation shall be performed. If any
operand is not a text file, the effects are unspecified.
- -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 ( "" )
shall 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 shall be searched for
only in directories named in -I options and then in the usual
places. Directories named in -I options shall be searched in the
order specified. Implementations shall support at least ten instances of
this option in a single c99 command invocation.
- -L directory
- 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 shall be searched in the order specified.
Implementations shall support at least ten instances of this option in a
single c99 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.
- -O optlevel
- Specify the level of code optimization. If the
optlevel option-argument is the digit '0' , all special code
optimizations shall be disabled. If it is the digit '1' , the
nature of the optimization is unspecified. If the -O option is
omitted, the nature of the system's default optimization is unspecified.
It is unspecified whether code generated in the presence of the -O
0 option is the same as that generated when -O is omitted. Other
optlevel values may be supported.
- -U name
- Remove any initial definition of name.
Multiple instances of the
-D,
-I,
-U, and
-L options
can be specified.
An
operand is either in the form of a pathname or the form
-l
library. The application shall ensure that at least one operand of the
pathname form is specified. The following operands shall be supported:
- file.c
- A C-language source file to be compiled and optionally
linked. The application shall ensure that the operand is of this form if
the -c option is used.
- file.a
- A library of object files typically produced by the
ar utility, and passed directly to the link editor. Implementations
may recognize implementation-defined suffixes other than .a as
denoting object file libraries.
- file.o
- An object file produced by c99 -c and passed
directly to the link editor. Implementations may recognize
implementation-defined suffixes other than .o as denoting object
files.
The processing of other files is implementation-defined.
- -l library
- (The letter ell.) Search the library named:
A library shall 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.
Implementations may recognize implementation-defined suffixes other than
.a as denoting libraries.
Not used.
The input file shall be one of the following: a text file containing a
C-language source program, an object file in the format produced by
c99
-c, or a library of object files, in the format produced by archiving
zero or more object files, using
ar. Implementations may supply
additional utilities that produce files in these formats. Additional input
file formats are implementation-defined.
The following environment variables shall affect the execution of
c99:
- LANG
- Provide a default value for the internationalization
variables that are unset or null. (See the Base Definitions volume of
IEEE Std 1003.1-2001, Section 8.2, Internationalization
Variables for the precedence of internationalization variables used to
determine the values of locale categories.)
- LC_ALL
- If set to a non-empty string value, override the values of
all the other internationalization variables.
- LC_CTYPE
- Determine the locale for the interpretation of sequences of
bytes of text data as characters (for example, single-byte 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 catalogs for the
processing of LC_MESSAGES .
- TMPDIR
- Provide a pathname that should override the default
directory for temporary files, if any. On XSI-conforming systems,
provide a pathname that shall override the default directory for temporary
files, if any.
Default.
If more than one
file operand ending in
.c (or possibly other
unspecified suffixes) is given, for each such file:
may be written. These messages, if written, shall precede the processing of each
input file; they shall not be written to the standard output if they are
written to the standard error, as described in the STDERR section.
If the
-E option is specified, the standard output shall 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.
The standard error shall be 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:
may be written to allow identification of the diagnostic and warning messages
with the appropriate input file. These messages, if written, shall precede the
processing of each input file; they shall not be written to the standard error
if they are written to the 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.
Object files or executable files or both are produced in unspecified formats.
The
c99 utility shall recognize the following
-l operands for
standard libraries:
- -l c
- This operand shall make visible all functions referenced in
the System Interfaces volume of IEEE Std 1003.1-2001, with
the possible exception of those functions listed as residing in
<aio.h>, <arpa/inet.h>,
<complex.h>, <fenv.h>, <math.h>,
<mqueue.h>, <netdb.h>,
<netinet/in.h>, <pthread.h>,
<sched.h>, <semaphore.h>,
<spawn.h>, <sys/socket.h>,
pthread_kill(), and pthread_sigmask() in
<signal.h>, <trace.h>, functions marked as
extensions other than as part of the MF or MPR extensions in
<sys/mman.h>, functions marked as ADV in
<fcntl.h>, and functions marked as CS, CPT, and TMR in
<time.h>. This operand shall not be required to be present to
cause a search of this library.
- -l l
- This operand shall make visible all functions required by
the C-language output of lex that are not made available through
the -l c operand.
- -l pthread
- This operand shall make visible all functions referenced in
<pthread.h> and pthread_kill() and
pthread_sigmask() referenced in <signal.h>. An
implementation may search this library in the absence of this
operand.
- -l m
- This operand shall make visible all functions referenced in
<math.h>, <complex.h>, and
<fenv.h>. An implementation may search this library in the
absence of this operand.
- -l rt
- This operand shall make visible all functions referenced in
<aio.h>, <mqueue.h>, <sched.h>,
<semaphore.h>, and <spawn.h>, functions marked
as extensions other than as part of the MF or MPR extensions in
<sys/mman.h>, functions marked as ADV in
<fcntl.h>, and functions marked as CS, CPT, and TMR in
<time.h>. An implementation may search this library in the
absence of this operand.
- -l trace
- This operand shall make visible all functions referenced in
<trace.h>. An implementation may search this library in the
absence of this operand.
- -l xnet
- This operand makes visible all functions referenced in
<arpa/inet.h>, <netdb.h>,
<netinet/in.h>, and <sys/socket.h>. An
implementation may search this library in the absence of this
operand.
- -l y
- This operand shall make visible all functions required by
the C-language output of yacc that are not made available through
the -l c operand.
In the absence of options that inhibit invocation of the link editor, such as
-c or
-E, the
c99 utility shall cause the equivalent of a
-l c operand to be passed to the link editor as the last
-l operand, causing it to be searched after all other object files and
libraries are loaded.
It is unspecified whether the libraries
libc.a,
libm.a,
librt.a,
libpthread.a,
libl.a,
liby.a, or
libxnet.a exist as regular files. The implementation may accept as
-l operands names of objects that do not exist as regular files.
The C compiler and link editor shall support the significance of external
symbols up to a length of at least 31 bytes; the action taken upon
encountering symbols exceeding the implementation-defined maximum symbol
length is unspecified.
The compiler and link editor shall support a minimum of 511 external symbols per
source or object file, and a minimum of 4095 external symbols in total. A
diagnostic message shall be written to the standard output if the
implementation-defined limit is exceeded; other actions are unspecified.
All implementations shall support one of the following programming environments
as a default. Implementations may support more than one of the following
programming environments. Applications can use
sysconf() or
getconf to determine which programming environments are supported.
Table: Programming Environments: Type Sizes
Programming Environment |
Bits in |
Bits in |
Bits in |
Bits in |
getconf Name |
int |
long |
pointer |
off_t |
_POSIX_V6_ILP32_OFF32 |
32 |
32 |
32 |
32 |
_POSIX_V6_ILP32_OFFBIG |
32 |
32 |
32 |
>=64 |
_POSIX_V6_LP64_OFF64 |
32 |
64 |
64 |
64 |
_POSIX_V6_LPBIG_OFFBIG |
>=32 |
>=64 |
>=64 |
>=64 |
All implementations shall support one or more environments where the widths of
the following types are no greater than the width of type
long:
blksize_t,
cc_t,
mode_t,
nfds_t,
pid_t,
ptrdiff_t,
size_t,
speed_t,
ssize_t,
suseconds_t,
tcflag_t,
useconds_t,
wchar_t,
wint_t
The executable files created when these environments are selected shall be in a
proper format for execution by the
exec family of functions. Each
environment may be one of the ones in Programming Environments: Type Sizes ,
or it may be another environment. The names for the environments that meet
this requirement shall be output by a
getconf command using the
_POSIX_V6_WIDTH_RESTRICTED_ENVS argument. If more than one environment meets
the requirement, the names of all such environments shall be output on
separate lines. Any of these names can then be used in a subsequent
getconf command to obtain the flags specific to that environment with
the following suffixes added as appropriate:
- _CFLAGS
- To get the C compiler flags.
- _LDFLAGS
- To get the linker/loader flags.
- _LIBS
- To get the libraries.
This requirement may be removed in a future version of
IEEE Std 1003.1.
When this utility processes a file containing a function called
main(),
it shall be defined with a return type equivalent to
int. Using return
from the initial call to
main() shall be equivalent (other than with
respect to language scope issues) to calling
exit() with the returned
value. Reaching the end of the initial call to
main() shall be
equivalent to calling
exit(0). The implementation shall not declare a
prototype for this function.
Implementations provide configuration strings for C compiler flags,
linker/loader flags, and libraries for each supported environment. When an
application needs to use a specific programming environment rather than the
implementation default programming environment while compiling, the
application shall first verify that the implementation supports the desired
environment. If the desired programming environment is supported, the
application shall then invoke
c99 with the appropriate C compiler flags
as the first options for the compile, the appropriate linker/loader flags
after any other options but before any operands, and the appropriate libraries
at the end of the operands.
Conforming applications shall not attempt to link together object files compiled
for different programming models. Applications shall also be aware that binary
data placed in shared memory or in files might not be recognized by
applications built for other programming models.
Table: Programming Environments: c99 and cc
Arguments
Programming Environment |
|
c99 and cc
Arguments |
getconf Name |
Use |
getconf Name |
_POSIX_V6_ILP32_OFF32 |
C Compiler Flags |
POSIX_V6_ILP32_OFF32_CFLAGS |
|
Linker/Loader Flags |
POSIX_V6_ILP32_OFF32_LDFLAGS |
|
Libraries |
POSIX_V6_ILP32_OFF32_LIBS |
_POSIX_V6_ILP32_OFFBIG |
C Compiler Flags |
POSIX_V6_ILP32_OFFBIG_CFLAGS |
|
Linker/Loader Flags |
POSIX_V6_ILP32_OFFBIG_LDFLAGS |
|
Libraries |
POSIX_V6_ILP32_OFFBIG_LIBS |
_POSIX_V6_LP64_OFF64 |
C Compiler Flags |
POSIX_V6_LP64_OFF64_CFLAGS |
|
Linker/Loader Flags |
POSIX_V6_LP64_OFF64_LDFLAGS |
|
Libraries |
POSIX_V6_LP64_OFF64_LIBS |
_POSIX_V6_LPBIG_OFFBIG |
C Compiler Flags |
POSIX_V6_LPBIG_OFFBIG_CFLAGS |
|
Linker/Loader Flags |
POSIX_V6_LPBIG_OFFBIG_LDFLAGS |
|
Libraries |
POSIX_V6_LPBIG_OFFBIG_LIBS |
The following exit values shall be returned:
- 0
- Successful compilation or link edit.
- >0
- An error occurred.
When
c99 encounters a compilation error that causes an object file not to
be created, it shall write a diagnostic to standard error and continue to
compile other source code operands, but it shall not perform the link phase
and return a non-zero exit status. If the link edit is unsuccessful, a
diagnostic message shall be written to standard error and
c99 exits
with a non-zero status. A conforming application shall rely on the exit status
of
c99, rather than on the existence or mode of the executable file.
The following sections are informative.
Since the
c99 utility usually creates files in the current directory
during the compilation process, it is typically necessary to run the
c99 utility in a directory in which a file can be created.
On systems providing POSIX Conformance (see the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 2, Conformance),
c99 is
required only with the C-Language Development option; XSI-conformant systems
always provide
c99.
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 conforming 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 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 behavior.
All of the functions specified in the System Interfaces volume of
IEEE Std 1003.1-2001 may be made visible by implementations when
the Standard C Library is searched. Conforming applications must explicitly
request searching the other standard libraries when functions made visible by
those libraries are used.
- 1.
- The following usage example compiles foo.c and
creates the executable file foo:
The following usage example compiles
foo.c and creates the object file
foo.o:
The following usage example compiles
foo.c and creates the executable
file
a.out:
The following usage example compiles
foo.c, links it with
bar.o,
and creates the executable file
a.out. It may also create and leave
foo.o:
- 2.
- The following example shows how an application using
threads interfaces can test for support of and use a programming
environment supporting 32-bit int, long, and pointer
types and an off_t type using at least 64 bits:
if [ $(getconf _POSIX_V6_ILP32_OFFBIG) != "-1" ]
then
c99 $(getconf POSIX_V6_ILP32_OFFBIG_CFLAGS) -D_XOPEN_SOURCE=600 \
$(getconf POSIX_V6_ILP32_OFFBIG_LDFLAGS) foo.c -o foo \
$(getconf POSIX_V6_ILP32_OFFBIG_LIBS) -l pthread
else
echo ILP32_OFFBIG programming environment not supported
exit 1
fi
- 3.
- The following examples clarify the use and interactions of
-L options and -l operands.
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:
c99 -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.
Multiple
-L operands can be used when library name collisions occur.
Building on the previous example, suppose that the user wants to use a new
libp.a, in
/a/a/a, but still wants
f() from
/a/b/c/libQ.a:
c99 -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.
- 4.
- The following example shows how an application can use a
programming environment where the widths of the following types:
blksize_t, cc_t, mode_t, nfds_t, pid_t,
ptrdiff_t, size_t, speed_t, ssize_t,
suseconds_t, tcflag_t, useconds_t, wchar_t,
wint_t
are no greater than the width of type
long:
# First choose one of the listed environments ...
# ... if there are no additional constraints, the first one will do:
CENV=$(getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS | head -n l)
# ... or, if an environment that supports large files is preferred,
# look for names that contain "OFF64" or "OFFBIG". (This chooses
# the last one in the list if none match.)
for CENV in $(getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS)
do
case $CENV in
*OFF64*|*OFFBIG*) break ;;
esac
done
# The chosen environment name can now be used like this:
c99 $(getconf ${CENV}_CFLAGS) -D _POSIX_C_SOURCE=200112L \
$(getconf ${CENV}_LDFLAGS) foo.c -o foo \
$(getconf ${CENV}_LIBS)
The
c99 utility is based on the
c89 utility originally introduced
in the ISO POSIX-2:1993 standard.
Some of the changes from
c89 include the modification to the contents of
the Standard Libraries section to account for new headers and options; for
example,
<spawn.h> added to the
-l rt operand, and
the
-l trace operand added for the Tracing functions.
None.
File Read, Write, and Creation ,
ar ,
getconf ,
make
,
nm ,
strip ,
umask() , the System Interfaces volume of
IEEE Std 1003.1-2001,
exec,
sysconf(), the Base
Definitions volume of IEEE Std 1003.1-2001, Chapter 13, Headers
Portions of this text are reprinted and reproduced in electronic form from IEEE
Std 1003.1, 2003 Edition, Standard for Information Technology -- Portable
Operating System Interface (POSIX), The Open Group Base Specifications Issue
6, Copyright (C) 2001-2003 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. In the event of any discrepancy between
this version and the original IEEE and The Open Group Standard, the original
IEEE and The Open Group Standard is the referee document. The original
Standard can be obtained online at http://www.opengroup.org/unix/online.html
.