Партнёры:
Хостинг:
c99 - compile standard C programs
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:
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.
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:
The processing of other files is implementation-defined.
liblibrary.a
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.
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:
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. 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:
"%s:\n", <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:
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:
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:
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.
The following usage example compiles foo.c and creates the executable file foo:
c99 -o foo foo.c
The following usage example compiles foo.c and creates the object file foo.o:
c99 -c foo.c
The following usage example compiles foo.c and creates the executable file a.out:
c99 foo.c
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:
c99 foo.c bar.o
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
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.
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.
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
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |