version 1, including all changes.
.
Rev |
Author |
# |
Line |
1 |
perry |
1 |
G++ |
|
|
2 |
!!!G++ |
|
|
3 |
NAME |
|
|
4 |
SYNOPSIS |
|
|
5 |
DESCRIPTION |
|
|
6 |
OPTIONS |
|
|
7 |
PRAGMAS |
|
|
8 |
FILES |
|
|
9 |
SEE ALSO |
|
|
10 |
BUGS |
|
|
11 |
COPYING |
|
|
12 |
AUTHORS |
|
|
13 |
---- |
|
|
14 |
!!NAME |
|
|
15 |
|
|
|
16 |
|
|
|
17 |
g++ - GNU project C++ Compiler |
|
|
18 |
!!SYNOPSIS |
|
|
19 |
|
|
|
20 |
|
|
|
21 |
g++ __[[__''option'' | ''filename'' |
|
|
22 |
]... |
|
|
23 |
!!DESCRIPTION |
|
|
24 |
|
|
|
25 |
|
|
|
26 |
The C and C++ compilers are integrated; __g++__ is a |
|
|
27 |
script to call __gcc with options to recognize C++. gcc__ |
|
|
28 |
processes input files through one or more of four stages: |
|
|
29 |
preprocessing, compilation, assembly, and linking. This man |
|
|
30 |
page contains full descriptions for ''only'' C++ specific |
|
|
31 |
aspects of the compiler, though it also contains summaries |
|
|
32 |
of some general-purpose options. For a fuller explanation of |
|
|
33 |
the compiler, see __gcc__(__1__). |
|
|
34 |
|
|
|
35 |
|
|
|
36 |
C++ source files use one of the suffixes `__.C__', |
|
|
37 |
`__.cc__', `__.cxx__', `__.cpp__', or |
|
|
38 |
`__.c++__'; preprocessed C++ files use the suffix |
|
|
39 |
`__.ii__'. |
|
|
40 |
!!OPTIONS |
|
|
41 |
|
|
|
42 |
|
|
|
43 |
There are many command-line options, including options to |
|
|
44 |
control details of optimization, warnings, and code |
|
|
45 |
generation, which are common to both __gcc__ and |
|
|
46 |
__g++__. For full information on all options, see |
|
|
47 |
__gcc__(__1__). |
|
|
48 |
|
|
|
49 |
|
|
|
50 |
Options must be separate: `__-dr__' is quite different |
|
|
51 |
from `__-d -r__ '. |
|
|
52 |
|
|
|
53 |
|
|
|
54 |
Most `__-f__' and `__-W__' options have two contrary |
|
|
55 |
forms: __-f__''name'' and __-fno-__''name'' (or |
|
|
56 |
__-W__''name'' and __-Wno-__''name''). Only the |
|
|
57 |
non-default forms are shown here. |
|
|
58 |
|
|
|
59 |
|
|
|
60 |
__-c__ |
|
|
61 |
|
|
|
62 |
|
|
|
63 |
Compile or assemble the source files, but do not link. The |
|
|
64 |
compiler output is an object file corresponding to each |
|
|
65 |
source file. |
|
|
66 |
|
|
|
67 |
|
|
|
68 |
__-D__''macro'' |
|
|
69 |
|
|
|
70 |
|
|
|
71 |
Define macro ''macro'' with the string `__1__' as its |
|
|
72 |
definition. |
|
|
73 |
|
|
|
74 |
|
|
|
75 |
__-D__''macro''__=__''defn'' |
|
|
76 |
|
|
|
77 |
|
|
|
78 |
Define macro ''macro'' as ''defn''. |
|
|
79 |
|
|
|
80 |
|
|
|
81 |
__-E__ |
|
|
82 |
|
|
|
83 |
|
|
|
84 |
Stop after the preprocessing stage; do not run the compiler |
|
|
85 |
proper. The output is preprocessed source code, which is |
|
|
86 |
sent to the standard output. |
|
|
87 |
|
|
|
88 |
|
|
|
89 |
__-fall-virtual__ |
|
|
90 |
|
|
|
91 |
|
|
|
92 |
Treat all possible member functions as virtual, implicitly. |
|
|
93 |
All member functions (except for constructor functions and |
|
|
94 |
__new__ or __delete__ member operators) are treated as |
|
|
95 |
virtual functions of the class where they |
|
|
96 |
appear. |
|
|
97 |
|
|
|
98 |
|
|
|
99 |
This does not mean that all calls to these member functions |
|
|
100 |
will be made through the internal table of virtual |
|
|
101 |
functions. Under some circumstances, the compiler can |
|
|
102 |
determine that a call to a given virtual function can be |
|
|
103 |
made directly; in these cases the calls are direct in any |
|
|
104 |
case. |
|
|
105 |
|
|
|
106 |
|
|
|
107 |
__-fdollars-in-identifiers__ |
|
|
108 |
|
|
|
109 |
|
|
|
110 |
Permit the use of `__$__' in identifiers. Traditional C |
|
|
111 |
allowed the character `__$__' to form part of |
|
|
112 |
identifiers; by default, GNU C also allows this. However, |
|
|
113 |
ANSI C forbids `__$__' in identifiers, and GNU C++ also |
|
|
114 |
forbids it by default on most platforms (though on some |
|
|
115 |
platforms it's enabled by default for GNU C++ as |
|
|
116 |
well). |
|
|
117 |
|
|
|
118 |
|
|
|
119 |
__-felide-constructors__ |
|
|
120 |
|
|
|
121 |
|
|
|
122 |
Use this option to instruct the compiler to be smarter about |
|
|
123 |
when it can elide constructors. Without this flag, GNU C++ |
|
|
124 |
and cfront both generate effectively the same code |
|
|
125 |
for: |
|
|
126 |
|
|
|
127 |
|
|
|
128 |
A foo (); |
|
|
129 |
A x (foo ()); // x initialized by `foo ()', no ctor |
|
|
130 |
called |
|
|
131 |
A y = foo (); // call to `foo ()' heads to temporary, |
|
|
132 |
// y is initialized from the temporary. |
|
|
133 |
|
|
|
134 |
|
|
|
135 |
Note the difference! With this flag, GNU C++ initializes |
|
|
136 |
`__y__' directly from the call to __foo ()__ without |
|
|
137 |
going through a temporary. |
|
|
138 |
|
|
|
139 |
|
|
|
140 |
__-fenum-int-equiv__ |
|
|
141 |
|
|
|
142 |
|
|
|
143 |
Normally GNU C++ allows conversion of __enum__ to |
|
|
144 |
__int__, but not the other way around. Use this option if |
|
|
145 |
you want GNU C++ to allow conversion of __int__ to |
|
|
146 |
__enum__ as well. |
|
|
147 |
|
|
|
148 |
|
|
|
149 |
__-fexternal-templates__ |
|
|
150 |
|
|
|
151 |
|
|
|
152 |
Produce smaller code for template declarations, by |
|
|
153 |
generating only a single copy of each template function |
|
|
154 |
where it is defined. To use this option successfully, you |
|
|
155 |
must also mark all files that use templates with either |
|
|
156 |
`__#pragma implementation__' (the definition) or |
|
|
157 |
`__#pragma interface__' (declarations). |
|
|
158 |
|
|
|
159 |
|
|
|
160 |
When your code is compiled with |
|
|
161 |
`__-fexternal-templates__', all template instantiations |
|
|
162 |
are external. You must arrange for all necessary |
|
|
163 |
instantiations to appear in the implementation file; you can |
|
|
164 |
do this with a __typedef__ that references each |
|
|
165 |
instantiation needed. Conversely, when you compile using the |
|
|
166 |
default option `__-fno-external-templates__', all |
|
|
167 |
template instantiations are explicitly |
|
|
168 |
internal. |
|
|
169 |
|
|
|
170 |
|
|
|
171 |
__-fno-gnu-linker__ |
|
|
172 |
|
|
|
173 |
|
|
|
174 |
Do not output global initializations (such as C++ |
|
|
175 |
constructors and destructors) in the form used by the GNU |
|
|
176 |
linker (on systems where the GNU linker is the standard |
|
|
177 |
method of handling them). Use this option when you want to |
|
|
178 |
use a non-GNU linker, which also requires using the |
|
|
179 |
__collect2__ program to make sure the system linker |
|
|
180 |
includes constructors and destructors. (__collect2__ is |
|
|
181 |
included in the GNU CC distribution.) For systems which |
|
|
182 |
''must'' use __collect2__, the compiler driver |
|
|
183 |
__gcc__ is configured to do this |
|
|
184 |
automatically. |
|
|
185 |
|
|
|
186 |
|
|
|
187 |
__-fmemoize-lookups__ |
|
|
188 |
|
|
|
189 |
|
|
|
190 |
__-fsave-memoized__ |
|
|
191 |
|
|
|
192 |
|
|
|
193 |
These flags are used to get the compiler to compile programs |
|
|
194 |
faster using heuristics. They are not on by default since |
|
|
195 |
they are only effective about half the time. The other half |
|
|
196 |
of the time programs compile more slowly (and take more |
|
|
197 |
memory). |
|
|
198 |
|
|
|
199 |
|
|
|
200 |
The first time the compiler must build a call to a member |
|
|
201 |
function (or reference to a data member), it must (1) |
|
|
202 |
determine whether the class implements member functions of |
|
|
203 |
that name; (2) resolve which member function to call (which |
|
|
204 |
involves figuring out what sorts of type conversions need to |
|
|
205 |
be made); and (3) check the visibility of the member |
|
|
206 |
function to the caller. All of this adds up to slower |
|
|
207 |
compilation. Normally, the second time a call is made to |
|
|
208 |
that member function (or reference to that data member), it |
|
|
209 |
must go through the same lengthy process again. This means |
|
|
210 |
that code like this |
|
|
211 |
|
|
|
212 |
|
|
|
213 |
cout |
|
|
214 |
|
|
|
215 |
|
|
|
216 |
makes six passes through all three steps. By using a |
|
|
217 |
software cache, a ``hit'' significantly reduces this cost. |
|
|
218 |
Unfortunately, using the cache introduces another layer of |
|
|
219 |
mechanisms which must be implemented, and so incurs its own |
|
|
220 |
overhead. `__-fmemoize-lookups__' enables the software |
|
|
221 |
cache. |
|
|
222 |
|
|
|
223 |
|
|
|
224 |
Because access privileges (visibility) to members and member |
|
|
225 |
functions may differ from one function context to the next, |
|
|
226 |
__g++__ may need to flush the cache. With the |
|
|
227 |
`__-fmemoize-lookups__' flag, the cache is flushed after |
|
|
228 |
every function that is compiled. The `-fsave-memoized' flag |
|
|
229 |
enables the same software cache, but when the compiler |
|
|
230 |
determines that the context of the last function compiled |
|
|
231 |
would yield the same access privileges of the next function |
|
|
232 |
to compile, it preserves the cache. This is most helpful |
|
|
233 |
when defining many member functions for the same class: with |
|
|
234 |
the exception of member functions which are friends of other |
|
|
235 |
classes, each member function has exactly the same access |
|
|
236 |
privileges as every other, and the cache need not be |
|
|
237 |
flushed. |
|
|
238 |
|
|
|
239 |
|
|
|
240 |
__-fno-default-inline__ |
|
|
241 |
|
|
|
242 |
|
|
|
243 |
Do not make member functions inline by default merely |
|
|
244 |
because they are defined inside the class scope. Otherwise, |
|
|
245 |
when you specify __-O__, member functions defined inside |
|
|
246 |
class scope are compiled inline by default; i.e., you don't |
|
|
247 |
need to add `__inline__' in front of the member function |
|
|
248 |
name. |
|
|
249 |
|
|
|
250 |
|
|
|
251 |
__-fno-strict-prototype__ |
|
|
252 |
|
|
|
253 |
|
|
|
254 |
Consider the declaration __int foo ();__. In C++, this |
|
|
255 |
means that the function __foo__ takes no arguments. In |
|
|
256 |
ANSI C, this is declared __int foo(void);__. With the |
|
|
257 |
flag `__-fno-strict-prototype__', declaring functions |
|
|
258 |
with no arguments is equivalent to declaring its argument |
|
|
259 |
list to be untyped, i.e., __int foo ();__ is equivalent |
|
|
260 |
to saying __int foo (...);__. |
|
|
261 |
|
|
|
262 |
|
|
|
263 |
__-fnonnull-objects__ |
|
|
264 |
|
|
|
265 |
|
|
|
266 |
Normally, GNU C++ makes conservative assumptions about |
|
|
267 |
objects reached through references. For example, the |
|
|
268 |
compiler must check that `__a__' is not null in code like |
|
|
269 |
the following: |
|
|
270 |
obj |
|
|
271 |
a.f (2); |
|
|
272 |
Checking that references of this sort have non-null values |
|
|
273 |
requires extra code, however, and it is unnecessary for many |
|
|
274 |
programs. You can use `__-fnonnull-objects__' to omit the |
|
|
275 |
checks for null, if your program doesn't require the default |
|
|
276 |
checking. |
|
|
277 |
|
|
|
278 |
|
|
|
279 |
__-fhandle-signatures__ |
|
|
280 |
|
|
|
281 |
|
|
|
282 |
__-fno-handle-signatures__ |
|
|
283 |
|
|
|
284 |
|
|
|
285 |
These options control the recognition of the |
|
|
286 |
__signature__ and __sigof__ constructs for specifying |
|
|
287 |
abstract types. By default, these constructs are not |
|
|
288 |
recognized. |
|
|
289 |
|
|
|
290 |
|
|
|
291 |
__-fthis-is-variable__ |
|
|
292 |
|
|
|
293 |
|
|
|
294 |
The incorporation of user-defined free store management into |
|
|
295 |
C++ has made assignment to __this__ an anachronism. |
|
|
296 |
Therefore, by default GNU C++ treats the type of __this__ |
|
|
297 |
in a member function of __class X__ to be __X |
|
|
298 |
*const__. In other words, it is illegal to assign to |
|
|
299 |
__this__ within a class member function. However, for |
|
|
300 |
backwards compatibility, you can invoke the old behavior by |
|
|
301 |
using `__-fthis-is-variable__'. |
|
|
302 |
|
|
|
303 |
|
|
|
304 |
__-g__ |
|
|
305 |
|
|
|
306 |
|
|
|
307 |
Produce debugging information in the operating system's |
|
|
308 |
native format (for DBX or SDB or DWARF). GDB also can work |
|
|
309 |
with this debugging information. On most systems that use |
|
|
310 |
DBX format, `__-g__' enables use of extra debugging |
|
|
311 |
information that only GDB can use. |
|
|
312 |
|
|
|
313 |
|
|
|
314 |
Unlike most other C compilers, GNU CC allows you to use |
|
|
315 |
`__-g__' with `__-O__'. The shortcuts taken by |
|
|
316 |
optimized code may occasionally produce surprising results: |
|
|
317 |
some variables you declared may not exist at all; flow of |
|
|
318 |
control may briefly move where you did not expect it; some |
|
|
319 |
statements may not be executed because they compute constant |
|
|
320 |
results or their values were already at hand; some |
|
|
321 |
statements may execute in different places because they were |
|
|
322 |
moved out of loops. |
|
|
323 |
|
|
|
324 |
|
|
|
325 |
Nevertheless it proves possible to debug optimized output. |
|
|
326 |
This makes it reasonable to use the optimizer for programs |
|
|
327 |
that might have bugs. |
|
|
328 |
|
|
|
329 |
|
|
|
330 |
__-I__''dir'' |
|
|
331 |
|
|
|
332 |
|
|
|
333 |
Append directory ''dir'' to the list of directories |
|
|
334 |
searched for include files. |
|
|
335 |
|
|
|
336 |
|
|
|
337 |
__-L__''dir'' |
|
|
338 |
|
|
|
339 |
|
|
|
340 |
Add directory ''dir'' to the list of directories to be |
|
|
341 |
searched for `__-l__'. |
|
|
342 |
|
|
|
343 |
|
|
|
344 |
__-l__''library'' |
|
|
345 |
|
|
|
346 |
|
|
|
347 |
Use the library named ''library'' when linking. (C++ |
|
|
348 |
programs often require `-lg++' for successful |
|
|
349 |
linking.) |
|
|
350 |
|
|
|
351 |
|
|
|
352 |
__-nostdinc__ |
|
|
353 |
|
|
|
354 |
|
|
|
355 |
Do not search the standard system directories for header |
|
|
356 |
files. Only the directories you have specified with |
|
|
357 |
__-I__ options (and the current directory, if |
|
|
358 |
appropriate) are searched. |
|
|
359 |
|
|
|
360 |
|
|
|
361 |
__-nostdinc++__ |
|
|
362 |
|
|
|
363 |
|
|
|
364 |
Do not search for header files in the standard directories |
|
|
365 |
specific to C++, but do still search the other standard |
|
|
366 |
directories. (This option is used when building |
|
|
367 |
libg++.) |
|
|
368 |
|
|
|
369 |
|
|
|
370 |
__-O__ |
|
|
371 |
|
|
|
372 |
|
|
|
373 |
Optimize. Optimizing compilation takes somewhat more time, |
|
|
374 |
and a lot more memory for a large function. |
|
|
375 |
|
|
|
376 |
|
|
|
377 |
__-o__ ''file'' |
|
|
378 |
|
|
|
379 |
|
|
|
380 |
Place output in file ''file''. |
|
|
381 |
|
|
|
382 |
|
|
|
383 |
__-S__ |
|
|
384 |
|
|
|
385 |
|
|
|
386 |
Stop after the stage of compilation proper; do not assemble. |
|
|
387 |
The output is an assembler code file for each non-assembler |
|
|
388 |
input file specified. |
|
|
389 |
|
|
|
390 |
|
|
|
391 |
__-traditional__ |
|
|
392 |
|
|
|
393 |
|
|
|
394 |
Attempt to support some aspects of traditional C |
|
|
395 |
compilers. |
|
|
396 |
|
|
|
397 |
|
|
|
398 |
Specifically, for both C and C++ programs: |
|
|
399 |
|
|
|
400 |
|
|
|
401 |
In the preprocessor, comments convert to nothing at all, |
|
|
402 |
rather than to a space. This allows traditional token |
|
|
403 |
concatenation. |
|
|
404 |
|
|
|
405 |
|
|
|
406 |
In the preprocessor, macro arguments are recognized within |
|
|
407 |
string constants in a macro definition (and their values are |
|
|
408 |
stringified, though without additional quote marks, when |
|
|
409 |
they appear in such a context). The preprocessor always |
|
|
410 |
considers a string constant to end at a |
|
|
411 |
newline. |
|
|
412 |
|
|
|
413 |
|
|
|
414 |
The preprocessor does not predefine the macro |
|
|
415 |
____STDC____ when you use `__-traditional__', but |
|
|
416 |
still predefines____GNUC____ (since the GNU extensions |
|
|
417 |
indicated by ____GNUC____ are not affected by |
|
|
418 |
`__-traditional__'). If you need to write header files |
|
|
419 |
that work differently depending on whether |
|
|
420 |
`__-traditional__' is in use, by testing both of these |
|
|
421 |
predefined macros you can distinguish four situations: GNU |
|
|
422 |
C, traditional GNU C, other ANSI C compilers, and other old |
|
|
423 |
C compilers. |
|
|
424 |
|
|
|
425 |
|
|
|
426 |
String ``constants'' are not necessarily constant; they are |
|
|
427 |
stored in writable space, and identical looking constants |
|
|
428 |
are allocated separately. |
|
|
429 |
|
|
|
430 |
|
|
|
431 |
For C++ programs only (not C), `__-traditional__' has one |
|
|
432 |
additional effect: assignment to __this__ is permitted. |
|
|
433 |
This is the same as the effect of |
|
|
434 |
`__-fthis-is-variable__'. |
|
|
435 |
|
|
|
436 |
|
|
|
437 |
__-U__''macro'' |
|
|
438 |
|
|
|
439 |
|
|
|
440 |
Undefine macro ''macro''. |
|
|
441 |
|
|
|
442 |
|
|
|
443 |
__-Wall__ |
|
|
444 |
|
|
|
445 |
|
|
|
446 |
Issue warnings for conditions which pertain to usage that we |
|
|
447 |
recommend avoiding and that we believe is easy to avoid, |
|
|
448 |
even in conjunction with macros. |
|
|
449 |
|
|
|
450 |
|
|
|
451 |
__-Wenum-clash__ |
|
|
452 |
|
|
|
453 |
|
|
|
454 |
Warn when converting between different enumeration |
|
|
455 |
types. |
|
|
456 |
|
|
|
457 |
|
|
|
458 |
__-Woverloaded-virtual__ |
|
|
459 |
|
|
|
460 |
|
|
|
461 |
In a derived class, the definitions of virtual functions |
|
|
462 |
must match the type signature of a virtual function declared |
|
|
463 |
in the base class. Use this option to request warnings when |
|
|
464 |
a derived class declares a function that may be an erroneous |
|
|
465 |
attempt to define a virtual function: that is, warn when a |
|
|
466 |
function with the same name as a virtual function in the |
|
|
467 |
base class, but with a type signature that doesn't match any |
|
|
468 |
virtual functions from the base class. |
|
|
469 |
|
|
|
470 |
|
|
|
471 |
__-Wtemplate-debugging__ |
|
|
472 |
|
|
|
473 |
|
|
|
474 |
When using templates in a C++ program, warn if debugging is |
|
|
475 |
not yet fully available. |
|
|
476 |
|
|
|
477 |
|
|
|
478 |
__-w__ |
|
|
479 |
|
|
|
480 |
|
|
|
481 |
Inhibit all warning messages. |
|
|
482 |
|
|
|
483 |
|
|
|
484 |
__+e__''N'' |
|
|
485 |
|
|
|
486 |
|
|
|
487 |
Control how virtual function definitions are used, in a |
|
|
488 |
fashion compatible with __cfront__ 1.x. |
|
|
489 |
!!PRAGMAS |
|
|
490 |
|
|
|
491 |
|
|
|
492 |
Two `__#pragma__' directives are supported for GNU C++, |
|
|
493 |
to permit using the same header file for two purposes: as a |
|
|
494 |
definition of interfaces to a given object class, and as the |
|
|
495 |
full definition of the contents of that object |
|
|
496 |
class. |
|
|
497 |
|
|
|
498 |
|
|
|
499 |
__#pragma interface__ |
|
|
500 |
|
|
|
501 |
|
|
|
502 |
Use this directive in header files that define object |
|
|
503 |
classes, to save space in most of the object files that use |
|
|
504 |
those classes. Normally, local copies of certain information |
|
|
505 |
(backup copies of inline member functions, debugging |
|
|
506 |
information, and the internal tables that implement virtual |
|
|
507 |
functions) must be kept in each object file that includes |
|
|
508 |
class definitions. You can use this pragma to avoid such |
|
|
509 |
duplication. When a header file containing `__#pragma |
|
|
510 |
interface__' is included in a compilation, this auxiliary |
|
|
511 |
information will not be generated (unless the main input |
|
|
512 |
source file itself uses `__#pragma implementation__'). |
|
|
513 |
Instead, the object files will contain references to be |
|
|
514 |
resolved at link time. |
|
|
515 |
|
|
|
516 |
|
|
|
517 |
__#pragma implementation__ |
|
|
518 |
|
|
|
519 |
|
|
|
520 |
__#pragma implementation |
|
|
521 |
__''objects''__.h__ |
|
|
522 |
|
|
|
523 |
|
|
|
524 |
Use this pragma in a main input file, when you want full |
|
|
525 |
output from included header files to be generated (and made |
|
|
526 |
globally visible). The included header file, in turn, should |
|
|
527 |
use `__#pragma interface__'. Backup copies of inline |
|
|
528 |
member functions, debugging information, and the internal |
|
|
529 |
tables used to implement virtual functions are all generated |
|
|
530 |
in implementation files. |
|
|
531 |
|
|
|
532 |
|
|
|
533 |
If you use `__#pragma implementation__' with no argument, |
|
|
534 |
it applies to an include file with the same basename as your |
|
|
535 |
source file; for example, in `__allclass.cc__', |
|
|
536 |
`__#pragma implementation__' by itself is equivalent to |
|
|
537 |
`__#pragma implementation __'. Use |
|
|
538 |
the string argument if you want a single implementation file |
|
|
539 |
to include code from multiple header files. |
|
|
540 |
|
|
|
541 |
|
|
|
542 |
There is no way to split up the contents of a single header |
|
|
543 |
file into multiple implementation files. |
|
|
544 |
!!FILES |
|
|
545 |
|
|
|
546 |
|
|
|
547 |
file.h C header (preprocessor) file |
|
|
548 |
file.i preprocessed C source file |
|
|
549 |
file.C C++ source file |
|
|
550 |
file.cc C++ source file |
|
|
551 |
file.cxx C++ source file |
|
|
552 |
file.s assembly language file |
|
|
553 |
file.o object file |
|
|
554 |
a.out link edited output'' |
|
|
555 |
TMPDIR''/cc temporary files'' |
|
|
556 |
LIBDIR''/cpp preprocessor'' |
|
|
557 |
LIBDIR''/cc1plus compiler'' |
|
|
558 |
LIBDIR''/collect linker front end needed on some |
|
|
559 |
machines'' |
|
|
560 |
LIBDIR''/libgcc.a GCC subroutine library |
|
|
561 |
/lib/crt[[01n].o start-up routine'' |
|
|
562 |
LIBDIR''/ccrt0 additional start-up routine for C++ |
|
|
563 |
/lib/libc.a standard C library, see intro(3) |
|
|
564 |
/usr/include standard directory for __#include__ |
|
|
565 |
files'' |
|
|
566 |
LIBDIR''/include standard gcc directory for |
|
|
567 |
__#include__ files'' |
|
|
568 |
LIBDIR''/g++-include additional g++ directory for |
|
|
569 |
__#include__ |
|
|
570 |
|
|
|
571 |
|
|
|
572 |
''LIBDIR'' is usually |
|
|
573 |
__/usr/local/lib/__''machine''/''version''.'' |
|
|
574 |
TMPDIR'' comes from the environment variable __TMPDIR__ |
|
|
575 |
(default __/usr/tmp__ if available, else |
|
|
576 |
__/tmp__). |
|
|
577 |
!!SEE ALSO |
|
|
578 |
|
|
|
579 |
|
|
|
580 |
gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), |
|
|
581 |
sdb(1). |
|
|
582 |
`__gcc__', `__cpp__', `__as__',__`__ld__',__ |
|
|
583 |
and `__gdb__' entries in __info__.'' |
|
|
584 |
Using and Porting GNU CC (for version 2.0)'', Richard M. |
|
|
585 |
Stallman; ''The C Preprocessor'', Richard M. Stallman; |
|
|
586 |
''Debugging with GDB: the GNU Source-Level Debugger'', |
|
|
587 |
Richard M. Stallman and Roland H. Pesch; ''Using as: the |
|
|
588 |
GNU Assembler'', Dean Elsner, Jay Fenlason |
|
|
589 |
''gld: the GNU linker'', Steve Chamberlain and Roland |
|
|
590 |
Pesch. |
|
|
591 |
!!BUGS |
|
|
592 |
|
|
|
593 |
|
|
|
594 |
For instructions on how to report bugs, see the GCC |
|
|
595 |
manual. |
|
|
596 |
!!COPYING |
|
|
597 |
|
|
|
598 |
|
|
|
599 |
Copyright (c) 1991, 1992, 1993 Free Software Foundation, |
|
|
600 |
Inc. |
|
|
601 |
|
|
|
602 |
|
|
|
603 |
Permission is granted to make and distribute verbatim copies |
|
|
604 |
of this manual provided the copyright notice and this |
|
|
605 |
permission notice are preserved on all copies. |
|
|
606 |
|
|
|
607 |
|
|
|
608 |
Permission is granted to copy and distribute modified |
|
|
609 |
versions of this manual under the conditions for verbatim |
|
|
610 |
copying, provided that the entire resulting derived work is |
|
|
611 |
distributed under the terms of a permission notice identical |
|
|
612 |
to this one. |
|
|
613 |
|
|
|
614 |
|
|
|
615 |
Permission is granted to copy and distribute translations of |
|
|
616 |
this manual into another language, under the above |
|
|
617 |
conditions for modified versions, except that this |
|
|
618 |
permission notice may be included in translations approved |
|
|
619 |
by the Free Software Foundation instead of in the original |
|
|
620 |
English. |
|
|
621 |
!!AUTHORS |
|
|
622 |
|
|
|
623 |
|
|
|
624 |
See the GNU CC Manual for the contributors to GNU |
|
|
625 |
CC. |
|
|
626 |
---- |