1C99(P) POSIX Programmer's Manual C99(P)
2
6 c99 - compile standard C programs
7
9 c99 [-c][-D name[=value]]...[-E][-g][-I directory] ... [-L directory]
10 ... [-o outfile][-Ooptlevel][-s][-U name]... operand ...
11
13 The c99 utility is an interface to the standard C compilation system;
14 it shall accept source code conforming to the ISO C standard. The sys‐
15 tem conceptually consists of a compiler and link editor. The files ref‐
16 erenced by operands shall be compiled and linked to produce an exe‐
17 cutable file. (It is unspecified whether the linking occurs entirely
18 within the operation of c99; some implementations may produce objects
19 that are not fully resolved until the file is executed.)
20 If the -c option is specified, for all pathname operands of the form
22 file .c, the files:
23 $(basename pathname .c).o
26 shall be created as the result of successful compilation. If the -c
28 option is not specified, it is unspecified whether such .o files are
29 created or deleted for the file .c operands.
30 If there are no options that prevent link editing (such as -c or -E),
32 and all operands compile and link without error, the resulting exe‐
33 cutable file shall be written according to the -o outfile option (if
34 present) or to the file a.out.
35 The executable file shall be created as specified in File Read, Write,
37 and Creation , except that the file permission bits shall be set to:
38 S_IRWXO | S_IRWXG | S_IRWXU
41 and the bits specified by the umask of the process shall be cleared.
43
45 The c99 utility shall conform to the Base Definitions volume of
46 IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines, except
47 that:
48 * The -l library operands have the format of options, but their posi‐
50 tion within a list of operands affects the order in which libraries
51 are searched.
52 * The order of specifying the -I and -L options is significant.
54 * Conforming applications shall specify each option separately; that
56 is, grouping option letters (for example, -cO) need not be recog‐
57 nized by all implementations.
58 The following options shall be supported:
60 -c Suppress the link-edit phase of the compilation, and do not
62 remove any object files that are produced.
63 -g Produce symbolic information in the object or executable files;
65 the nature of this information is unspecified, and may be modi‐
66 fied by implementation-defined interactions with other options.
67 -s Produce object or executable files, or both, from which symbolic
69 and other information not required for proper execution using
70 the exec family defined in the System Interfaces volume of
71 IEEE Std 1003.1-2001 has been removed (stripped). If both -g and
72 -s options are present, the action taken is unspecified.
73 -o outfile
75 Use the pathname outfile, instead of the default a.out, for the
76 executable file produced. If the -o option is present with -c or
77 -E, the result is unspecified.
78 -D name[=value]
80 Define name as if by a C-language #define directive. If no =
82 value is given, a value of 1 shall be used. The -D option has
83 lower precedence than the -U option. That is, if name is used in
84 both a -U and a -D option, name shall be undefined regardless of
85 the order of the options. Additional implementation-defined
86 names may be provided by the compiler. Implementations shall
87 support at least 2048 bytes of -D definitions and 256 names.
88 -E Copy C-language source files to standard output, expanding all
90 preprocessor directives; no compilation shall be performed. If
91 any operand is not a text file, the effects are unspecified.
92 -I directory
94 Change the algorithm for searching for headers whose names are
95 not absolute pathnames to look in the directory named by the
96 directory pathname before looking in the usual places. Thus,
97 headers whose names are enclosed in double-quotes ( "" ) shall
98 be searched for first in the directory of the file with the
99 #include line, then in directories named in -I options, and last
100 in the usual places. For headers whose names are enclosed in
101 angle brackets ( "<>" ), the header shall be searched for only
102 in directories named in -I options and then in the usual places.
103 Directories named in -I options shall be searched in the order
104 specified. Implementations shall support at least ten instances
105 of this option in a single c99 command invocation.
106 -L directory
108 Change the algorithm of searching for the libraries named in the
109 -l objects to look in the directory named by the directory path‐
110 name before looking in the usual places. Directories named in -L
111 options shall be searched in the order specified. Implementa‐
112 tions shall support at least ten instances of this option in a
113 single c99 command invocation. If a directory specified by a -L
114 option contains files named libc.a, libm.a, libl.a, or liby.a,
115 the results are unspecified.
116 -O optlevel
118 Specify the level of code optimization. If the optlevel option-
119 argument is the digit '0' , all special code optimizations shall
120 be disabled. If it is the digit '1' , the nature of the opti‐
121 mization is unspecified. If the -O option is omitted, the nature
122 of the system's default optimization is unspecified. It is
123 unspecified whether code generated in the presence of the -O 0
124 option is the same as that generated when -O is omitted. Other
125 optlevel values may be supported.
126 -U name
128 Remove any initial definition of name.
129 Multiple instances of the -D, -I, -U, and -L options can be specified.
132
134 An operand is either in the form of a pathname or the form -l library.
135 The application shall ensure that at least one operand of the pathname
136 form is specified. The following operands shall be supported:
137 file.c A C-language source file to be compiled and optionally linked.
139 The application shall ensure that the operand is of this form if
140 the -c option is used.
141 file.a A library of object files typically produced by the ar utility,
143 and passed directly to the link editor. Implementations may rec‐
144 ognize implementation-defined suffixes other than .a as denoting
145 object file libraries.
146 file.o An object file produced by c99 -c and passed directly to the
148 link editor. Implementations may recognize implementation-
149 defined suffixes other than .o as denoting object files.
150 The processing of other files is implementation-defined.
153 -l library
155 (The letter ell.) Search the library named:
156 liblibrary.a
159 A library shall be searched when its name is encountered, so the place‐
161 ment of a -l operand is significant. Several standard libraries can be
162 specified in this manner, as described in the EXTENDED DESCRIPTION sec‐
163 tion. Implementations may recognize implementation-defined suffixes
164 other than .a as denoting libraries.
165
168 Not used.
169
171 The input file shall be one of the following: a text file containing a
172 C-language source program, an object file in the format produced by c99
173 -c, or a library of object files, in the format produced by archiving
174 zero or more object files, using ar. Implementations may supply addi‐
175 tional utilities that produce files in these formats. Additional input
176 file formats are implementation-defined.
177
179 The following environment variables shall affect the execution of c99:
180 LANG Provide a default value for the internationalization variables
182 that are unset or null. (See the Base Definitions volume of
183 IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
184 ables for the precedence of internationalization variables used
185 to determine the values of locale categories.)
186 LC_ALL If set to a non-empty string value, override the values of all
188 the other internationalization variables.
189 LC_CTYPE
191 Determine the locale for the interpretation of sequences of
192 bytes of text data as characters (for example, single-byte as
193 opposed to multi-byte characters in arguments and input files).
194 LC_MESSAGES
196 Determine the locale that should be used to affect the format
197 and contents of diagnostic messages written to standard error.
198 NLSPATH
200 Determine the location of message catalogs for the processing of
201 LC_MESSAGES .
202 TMPDIR Provide a pathname that should override the default directory
204 for temporary files, if any. On XSI-conforming systems, pro‐
205 vide a pathname that shall override the default directory for
206 temporary files, if any.
207
210 Default.
211
213 If more than one file operand ending in .c (or possibly other unspeci‐
214 fied suffixes) is given, for each such file:
215 "%s:\n", <file>
218 may be written. These messages, if written, shall precede the process‐
220 ing of each input file; they shall not be written to the standard out‐
221 put if they are written to the standard error, as described in the
222 STDERR section.
223 If the -E option is specified, the standard output shall be a text file
225 that represents the results of the preprocessing stage of the language;
226 it may contain extra information appropriate for subsequent compilation
227 passes.
228
230 The standard error shall be used only for diagnostic messages. If more
231 than one file operand ending in .c (or possibly other unspecified suf‐
232 fixes) is given, for each such file:
233 "%s:\n", <file>
236 may be written to allow identification of the diagnostic and warning
238 messages with the appropriate input file. These messages, if written,
239 shall precede the processing of each input file; they shall not be
240 written to the standard error if they are written to the standard out‐
241 put, as described in the STDOUT section.
242 This utility may produce warning messages about certain conditions that
244 do not warrant returning an error (non-zero) exit value.
245
247 Object files or executable files or both are produced in unspecified
248 formats.
249
251 Standard Libraries
252 The c99 utility shall recognize the following -l operands for standard
253 libraries:
254 -l c This operand shall make visible all functions referenced in the
256 System Interfaces volume of IEEE Std 1003.1-2001, with the pos‐
257 sible exception of those functions listed as residing in
258 <aio.h>, <arpa/inet.h>, <complex.h>, <fenv.h>, <math.h>,
259 <mqueue.h>, <netdb.h>, <netinet/in.h>, <pthread.h>, <sched.h>,
260 <semaphore.h>, <spawn.h>, <sys/socket.h>, pthread_kill(), and
261 pthread_sigmask() in <signal.h>, <trace.h>, functions marked as
262 extensions other than as part of the MF or MPR extensions in
263 <sys/mman.h>, functions marked as ADV in <fcntl.h>, and func‐
264 tions marked as CS, CPT, and TMR in <time.h>. This operand shall
265 not be required to be present to cause a search of this library.
266 -l l This operand shall make visible all functions required by the C-
268 language output of lex that are not made available through the
269 -l c operand.
270 -l pthread
272 This operand shall make visible all functions referenced in
273 <pthread.h> and pthread_kill() and pthread_sigmask() referenced
274 in <signal.h>. An implementation may search this library in the
275 absence of this operand.
276 -l m This operand shall make visible all functions referenced in
278 <math.h>, <complex.h>, and <fenv.h>. An implementation may
279 search this library in the absence of this operand.
280 -l rt This operand shall make visible all functions referenced in
282 <aio.h>, <mqueue.h>, <sched.h>, <semaphore.h>, and <spawn.h>,
283 functions marked as extensions other than as part of the MF or
284 MPR extensions in <sys/mman.h>, functions marked as ADV in
285 <fcntl.h>, and functions marked as CS, CPT, and TMR in <time.h>.
286 An implementation may search this library in the absence of this
287 operand.
288 -l trace
290 This operand shall make visible all functions referenced in
291 <trace.h>. An implementation may search this library in the
292 absence of this operand.
293 -l xnet
295 This operand makes visible all functions referenced in
296 <arpa/inet.h>, <netdb.h>, <netinet/in.h>, and <sys/socket.h>. An
297 implementation may search this library in the absence of this
298 operand.
299 -l y This operand shall make visible all functions required by the C-
301 language output of yacc that are not made available through the
302 -l c operand.
303 In the absence of options that inhibit invocation of the link editor,
306 such as -c or -E, the c99 utility shall cause the equivalent of a -l c
307 operand to be passed to the link editor as the last -l operand, causing
308 it to be searched after all other object files and libraries are
309 loaded.
310 It is unspecified whether the libraries libc.a, libm.a, librt.a,
312 libpthread.a, libl.a, liby.a, or libxnet.a exist as regular files. The
313 implementation may accept as -l operands names of objects that do not
314 exist as regular files.
315 External Symbols
317 The C compiler and link editor shall support the significance of exter‐
318 nal symbols up to a length of at least 31 bytes; the action taken upon
319 encountering symbols exceeding the implementation-defined maximum sym‐
320 bol length is unspecified.
321 The compiler and link editor shall support a minimum of 511 external
323 symbols per source or object file, and a minimum of 4095 external sym‐
324 bols in total. A diagnostic message shall be written to the standard
325 output if the implementation-defined limit is exceeded; other actions
326 are unspecified.
327 Programming Environments
329 All implementations shall support one of the following programming
330 environments as a default. Implementations may support more than one of
331 the following programming environments. Applications can use sysconf()
332 or getconf to determine which programming environments are supported.
333 Table: Programming Environments: Type Sizes
335 Programming Environment Bits in Bits in Bits in Bits in
337 getconf Name int long pointer off_t
338 _POSIX_V6_ILP32_OFF32 32 32 32 32
339 _POSIX_V6_ILP32_OFFBIG 32 32 32 >=64
340 _POSIX_V6_LP64_OFF64 32 64 64 64
341 _POSIX_V6_LPBIG_OFFBIG >=32 >=64 >=64 >=64
342 All implementations shall support one or more environments where the
344 widths of the following types are no greater than the width of type
345 long: blksize_t, cc_t, mode_t, nfds_t, pid_t, ptrdiff_t, size_t,
346 speed_t, ssize_t, suseconds_t, tcflag_t, useconds_t, wchar_t, wint_t
347 The executable files created when these environments are selected shall
349 be in a proper format for execution by the exec family of functions.
350 Each environment may be one of the ones in Programming Environments:
351 Type Sizes , or it may be another environment. The names for the envi‐
352 ronments that meet this requirement shall be output by a getconf com‐
353 mand using the _POSIX_V6_WIDTH_RESTRICTED_ENVS argument. If more than
354 one environment meets the requirement, the names of all such environ‐
355 ments shall be output on separate lines. Any of these names can then be
356 used in a subsequent getconf command to obtain the flags specific to
357 that environment with the following suffixes added as appropriate:
358 _CFLAGS
360 To get the C compiler flags.
361 _LDFLAGS
363 To get the linker/loader flags.
364 _LIBS To get the libraries.
366 This requirement may be removed in a future version of IEEE Std 1003.1.
369 When this utility processes a file containing a function called main(),
371 it shall be defined with a return type equivalent to int. Using return
372 from the initial call to main() shall be equivalent (other than with
373 respect to language scope issues) to calling exit() with the returned
374 value. Reaching the end of the initial call to main() shall be equiva‐
375 lent to calling exit(0). The implementation shall not declare a proto‐
376 type for this function.
377 Implementations provide configuration strings for C compiler flags,
379 linker/loader flags, and libraries for each supported environment. When
380 an application needs to use a specific programming environment rather
381 than the implementation default programming environment while compil‐
382 ing, the application shall first verify that the implementation sup‐
383 ports the desired environment. If the desired programming environment
384 is supported, the application shall then invoke c99 with the appropri‐
385 ate C compiler flags as the first options for the compile, the appro‐
386 priate linker/loader flags after any other options but before any oper‐
387 ands, and the appropriate libraries at the end of the operands.
388 Conforming applications shall not attempt to link together object files
390 compiled for different programming models. Applications shall also be
391 aware that binary data placed in shared memory or in files might not be
392 recognized by applications built for other programming models.
393 Table: Programming Environments: c99 and cc Arguments
395 Programming Environment c99 and cc Arguments
398 getconf Name Use getconf Name
399 _POSIX_V6_ILP32_OFF32 C Compiler Flags POSIX_V6_ILP32_OFF32_CFLAGS
400 Linker/Loader Flags POSIX_V6_ILP32_OFF32_LDFLAGS
401 Libraries POSIX_V6_ILP32_OFF32_LIBS
402 _POSIX_V6_ILP32_OFFBIG C Compiler Flags POSIX_V6_ILP32_OFFBIG_CFLAGS
403 Linker/Loader Flags POSIX_V6_ILP32_OFFBIG_LDFLAGS
404 Libraries POSIX_V6_ILP32_OFFBIG_LIBS
405 _POSIX_V6_LP64_OFF64 C Compiler Flags POSIX_V6_LP64_OFF64_CFLAGS
406 Linker/Loader Flags POSIX_V6_LP64_OFF64_LDFLAGS
407 Libraries POSIX_V6_LP64_OFF64_LIBS
408 _POSIX_V6_LPBIG_OFFBIG C Compiler Flags POSIX_V6_LPBIG_OFFBIG_CFLAGS
409 Linker/Loader Flags POSIX_V6_LPBIG_OFFBIG_LDFLAGS
410 Libraries POSIX_V6_LPBIG_OFFBIG_LIBS
411
413 The following exit values shall be returned:
414 0 Successful compilation or link edit.
416 >0 An error occurred.
418
421 When c99 encounters a compilation error that causes an object file not
422 to be created, it shall write a diagnostic to standard error and con‐
423 tinue to compile other source code operands, but it shall not perform
424 the link phase and return a non-zero exit status. If the link edit is
425 unsuccessful, a diagnostic message shall be written to standard error
426 and c99 exits with a non-zero status. A conforming application shall
427 rely on the exit status of c99, rather than on the existence or mode of
428 the executable file.
429 The following sections are informative.
431
433 Since the c99 utility usually creates files in the current directory
434 during the compilation process, it is typically necessary to run the
435 c99 utility in a directory in which a file can be created.
436 On systems providing POSIX Conformance (see the Base Definitions volume
438 of IEEE Std 1003.1-2001, Chapter 2, Conformance), c99 is required only
439 with the C-Language Development option; XSI-conformant systems always
440 provide c99.
441 Some historical implementations have created .o files when -c is not
443 specified and more than one source file is given. Since this area is
444 left unspecified, the application cannot rely on .o files being cre‐
445 ated, but it also must be prepared for any related .o files that
446 already exist being deleted at the completion of the link edit.
447 Some historical implementations have permitted -L options to be inter‐
449 spersed with -l operands on the command line. For an application to
450 compile consistently on systems that do not behave like this, it is
451 necessary for a conforming application to supply all -L options before
452 any of the -l options.
453 There is the possible implication that if a user supplies versions of
455 the standard functions (before they would be encountered by an implicit
456 -l c or explicit -l m), that those versions would be used in place of
457 the standard versions. There are various reasons this might not be
458 true (functions defined as macros, manipulations for clean name space,
459 and so on), so the existence of files named in the same manner as the
460 standard libraries within the -L directories is explicitly stated to
461 produce unspecified behavior.
462 All of the functions specified in the System Interfaces volume of
464 IEEE Std 1003.1-2001 may be made visible by implementations when the
465 Standard C Library is searched. Conforming applications must explicitly
466 request searching the other standard libraries when functions made vis‐
467 ible by those libraries are used.
468
470 1. The following usage example compiles foo.c and creates the exe‐
471 cutable file foo:
472 c99 -o foo foo.c
475 The following usage example compiles foo.c and creates the object file
477 foo.o:
478 c99 -c foo.c
481 The following usage example compiles foo.c and creates the executable
483 file a.out:
484 c99 foo.c
487 The following usage example compiles foo.c, links it with bar.o, and
489 creates the executable file a.out. It may also create and leave foo.o:
490 c99 foo.c bar.o
493 2. The following example shows how an application using threads inter‐
495 faces can test for support of and use a programming environment
496 supporting 32-bit int, long, and pointer types and an off_t type
497 using at least 64 bits:
498 if [ $(getconf _POSIX_V6_ILP32_OFFBIG) != "-1" ]
501 then
502 c99 $(getconf POSIX_V6_ILP32_OFFBIG_CFLAGS) -D_XOPEN_SOURCE=600 \
503 $(getconf POSIX_V6_ILP32_OFFBIG_LDFLAGS) foo.c -o foo \
504 $(getconf POSIX_V6_ILP32_OFFBIG_LIBS) -l pthread
505 else
506 echo ILP32_OFFBIG programming environment not supported
507 exit 1
508 fi
509 3. The following examples clarify the use and interactions of -L
511 options and -l operands.
512 Consider the case in which module a.c calls function f() in library
514 libQ.a, and module b.c calls function g() in library libp.a. Assume
515 that both libraries reside in /a/b/c. The command line to compile and
516 link in the desired way is:
517 c99 -L /a/b/c main.o a.c -l Q b.c -l p
520 In this case the -l Q operand need only precede the first -l p operand,
522 since both libQ.a and libp.a reside in the same directory.
523 Multiple -L operands can be used when library name collisions occur.
525 Building on the previous example, suppose that the user wants to use a
526 new libp.a, in /a/a/a, but still wants f() from /a/b/c/libQ.a:
527 c99 -L /a/a/a -L /a/b/c main.o a.c -l Q b.c -l p
530 In this example, the linker searches the -L options in the order speci‐
532 fied, and finds /a/a/a/libp.a before /a/b/c/libp.a when resolving ref‐
533 erences for b.c. The order of the -l operands is still important, how‐
534 ever.
535 4. The following example shows how an application can use a program‐
537 ming environment where the widths of the following types: blk‐
538 size_t, cc_t, mode_t, nfds_t, pid_t, ptrdiff_t, size_t, speed_t,
539 ssize_t, suseconds_t, tcflag_t, useconds_t, wchar_t, wint_t
540 are no greater than the width of type long:
542 # First choose one of the listed environments ...
545 # ... if there are no additional constraints, the first one will do:
548 CENV=$(getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS | head -n l)
549 # ... or, if an environment that supports large files is preferred,
552 # look for names that contain "OFF64" or "OFFBIG". (This chooses
553 # the last one in the list if none match.)
554 for CENV in $(getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS)
555 do
556 case $CENV in
557 *OFF64*|*OFFBIG*) break ;;
558 esac
559 done
560 # The chosen environment name can now be used like this:
563 c99 $(getconf ${CENV}_CFLAGS) -D _POSIX_C_SOURCE=200112L \
566 $(getconf ${CENV}_LDFLAGS) foo.c -o foo \
567 $(getconf ${CENV}_LIBS)
568
570 The c99 utility is based on the c89 utility originally introduced in
571 the ISO POSIX-2:1993 standard.
572 Some of the changes from c89 include the modification to the contents
574 of the Standard Libraries section to account for new headers and
575 options; for example, <spawn.h> added to the -l rt operand, and the -l
576 trace operand added for the Tracing functions.
577
579 None.
580
582 File Read, Write, and Creation , ar , getconf , make , nm , strip ,
583 umask() , the System Interfaces volume of IEEE Std 1003.1-2001, exec,
584 sysconf(), the Base Definitions volume of IEEE Std 1003.1-2001, Chapter
585 13, Headers
586
588 Portions of this text are reprinted and reproduced in electronic form
589 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
590 -- Portable Operating System Interface (POSIX), The Open Group Base
591 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
592 Electrical and Electronics Engineers, Inc and The Open Group. In the
593 event of any discrepancy between this version and the original IEEE and
594 The Open Group Standard, the original IEEE and The Open Group Standard
595 is the referee document. The original Standard can be obtained online
596 at http://www.opengroup.org/unix/online.html .
597IEEE/The Open Group 2003 C99(P)