675 lines
19 KiB
Groff
675 lines
19 KiB
Groff
|
.\" Copyright (c) 1991, 1992 Free Software Foundation -*-Text-*-
|
||
|
.\" See section COPYING for conditions for redistribution
|
||
|
.\" FIXME: no info here on predefines. Should there be? extra for C++...
|
||
|
.TH G++ 1 "30apr1993" "GNU Tools" "GNU Tools"
|
||
|
.de BP
|
||
|
.sp
|
||
|
.ti \-.2i
|
||
|
\(**
|
||
|
..
|
||
|
.SH NAME
|
||
|
g++ \- GNU project C++ Compiler
|
||
|
.SH SYNOPSIS
|
||
|
.RB g++ " [" \c
|
||
|
.IR option " | " filename " ].\|.\|.
|
||
|
.SH DESCRIPTION
|
||
|
The C and C++ compilers are integrated;
|
||
|
.B g++
|
||
|
is a script to call
|
||
|
.B gcc with options to recognize C++.
|
||
|
.B gcc
|
||
|
processes input files
|
||
|
through one or more of four stages: preprocessing, compilation,
|
||
|
assembly, and linking. This man page contains full descriptions for
|
||
|
.I only
|
||
|
C++ specific aspects of the compiler, though it also contains
|
||
|
summaries of some general-purpose options. For a fuller explanation
|
||
|
of the compiler, see
|
||
|
.BR gcc ( 1 ).
|
||
|
|
||
|
C++ source files use one of the suffixes `\|\c
|
||
|
.B .C\c
|
||
|
\&\|', `\|\c
|
||
|
.B .cc\c
|
||
|
\&\|', `\|\c
|
||
|
.B .cxx\c
|
||
|
\&\|', `\|\c
|
||
|
.B .cpp\c
|
||
|
\&\|', or `\|\c
|
||
|
.B .c++\c
|
||
|
\&\|'; preprocessed C++ files use the suffix `\|\c
|
||
|
.B .ii\c
|
||
|
\&\|'.
|
||
|
.SH OPTIONS
|
||
|
There are many command-line options, including options to control
|
||
|
details of optimization, warnings, and code generation, which are
|
||
|
common to both
|
||
|
.B gcc
|
||
|
and
|
||
|
.B g++\c
|
||
|
\&. For full information on all options, see
|
||
|
.BR gcc ( 1 ).
|
||
|
|
||
|
Options must be separate: `\|\c
|
||
|
.B \-dr\c
|
||
|
\&\|' is quite different from `\|\c
|
||
|
.B \-d \-r
|
||
|
\&\|'.
|
||
|
|
||
|
Most `\|\c
|
||
|
.B \-f\c
|
||
|
\&\|' and `\|\c
|
||
|
.B \-W\c
|
||
|
\&\|' options have two contrary forms:
|
||
|
.BI \-f name
|
||
|
and
|
||
|
.BI \-fno\- name\c
|
||
|
\& (or
|
||
|
.BI \-W name
|
||
|
and
|
||
|
.BI \-Wno\- name\c
|
||
|
\&). Only the non-default forms are shown here.
|
||
|
|
||
|
.TP
|
||
|
.B \-c
|
||
|
Compile or assemble the source files, but do not link. The compiler
|
||
|
output is an object file corresponding to each source file.
|
||
|
.TP
|
||
|
.BI \-D macro
|
||
|
Define macro \c
|
||
|
.I macro\c
|
||
|
\& with the string `\|\c
|
||
|
.B 1\c
|
||
|
\&\|' as its definition.
|
||
|
.TP
|
||
|
.BI \-D macro = defn
|
||
|
Define macro \c
|
||
|
.I macro\c
|
||
|
\& as \c
|
||
|
.I defn\c
|
||
|
\&.
|
||
|
.TP
|
||
|
.B \-E
|
||
|
Stop after the preprocessing stage; do not run the compiler proper. The
|
||
|
output is preprocessed source code, which is sent to the
|
||
|
standard output.
|
||
|
.TP
|
||
|
.B \-fall\-virtual
|
||
|
Treat all possible member functions as virtual, implicitly. All
|
||
|
member functions (except for constructor functions and
|
||
|
.B new
|
||
|
or
|
||
|
.B delete
|
||
|
member operators) are treated as virtual functions of the class where
|
||
|
they appear.
|
||
|
|
||
|
This does not mean that all calls to these member functions will be
|
||
|
made through the internal table of virtual functions. Under some
|
||
|
circumstances, the compiler can determine that a call to a given
|
||
|
virtual function can be made directly; in these cases the calls are
|
||
|
direct in any case.
|
||
|
.TP
|
||
|
.B \-fdollars\-in\-identifiers
|
||
|
Permit the use of `\|\c
|
||
|
.B $\c
|
||
|
\&\|' in identifiers.
|
||
|
Traditional C allowed the character `\|\c
|
||
|
.B $\c
|
||
|
\&\|' to form part of identifiers; by default, GNU C also
|
||
|
allows this. However, ANSI C forbids `\|\c
|
||
|
.B $\c
|
||
|
\&\|' in identifiers, and GNU C++ also forbids it by default on most
|
||
|
platforms (though on some platforms it's enabled by default for GNU
|
||
|
C++ as well).
|
||
|
.TP
|
||
|
.B \-felide\-constructors
|
||
|
Use this option to instruct the compiler to be smarter about when it can
|
||
|
elide constructors. Without this flag, GNU C++ and cfront both
|
||
|
generate effectively the same code for:
|
||
|
.sp
|
||
|
.br
|
||
|
A\ foo\ ();
|
||
|
.br
|
||
|
A\ x\ (foo\ ());\ \ \ //\ x\ initialized\ by\ `foo\ ()',\ no\ ctor\ called
|
||
|
.br
|
||
|
A\ y\ =\ foo\ ();\ \ \ //\ call\ to\ `foo\ ()'\ heads\ to\ temporary,
|
||
|
.br
|
||
|
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ //\ y\ is\ initialized\ from\ the\ temporary.
|
||
|
.br
|
||
|
.sp
|
||
|
Note the difference! With this flag, GNU C++ initializes `\|\c
|
||
|
.B y\c
|
||
|
\&\|' directly
|
||
|
from the call to
|
||
|
.B foo ()
|
||
|
without going through a temporary.
|
||
|
.TP
|
||
|
.B \-fenum\-int\-equiv
|
||
|
Normally GNU C++ allows conversion of
|
||
|
.B enum
|
||
|
to
|
||
|
.B int\c
|
||
|
\&, but not the other way around. Use this option if you want GNU C++
|
||
|
to allow conversion of
|
||
|
.B int
|
||
|
to
|
||
|
.B enum
|
||
|
as well.
|
||
|
.TP
|
||
|
.B \-fexternal\-templates
|
||
|
Produce smaller code for template declarations, by generating only a
|
||
|
single copy of each template function where it is defined.
|
||
|
To use this option successfully, you must also mark all files that
|
||
|
use templates with either `\|\c
|
||
|
.B #pragma implementation\c
|
||
|
\&\|' (the definition) or
|
||
|
`\|\c
|
||
|
.B #pragma interface\c
|
||
|
\&\|' (declarations).
|
||
|
|
||
|
When your code is compiled with `\|\c
|
||
|
.B \-fexternal\-templates\c
|
||
|
\&\|', all
|
||
|
template instantiations are external. You must arrange for all
|
||
|
necessary instantiations to appear in the implementation file; you can
|
||
|
do this with a \c
|
||
|
.B typedef\c
|
||
|
\& that references each instantiation needed.
|
||
|
Conversely, when you compile using the default option
|
||
|
`\|\c
|
||
|
.B \-fno\-external\-templates\c
|
||
|
\&\|', all template instantiations are
|
||
|
explicitly internal.
|
||
|
.TP
|
||
|
.B \-fno\-gnu\-linker
|
||
|
Do not output global initializations (such as C++ constructors and
|
||
|
destructors) in the form used by the GNU linker (on systems where the GNU
|
||
|
linker is the standard method of handling them). Use this option when
|
||
|
you want to use a non-GNU linker, which also requires using the
|
||
|
.B collect2
|
||
|
program to make sure the system linker includes
|
||
|
constructors and destructors. (\c
|
||
|
.B collect2
|
||
|
is included in the GNU CC distribution.) For systems which
|
||
|
.I must
|
||
|
use
|
||
|
.B collect2\c
|
||
|
\&, the compiler driver
|
||
|
.B gcc
|
||
|
is configured to do this automatically.
|
||
|
.TP
|
||
|
.B \-fmemoize\-lookups
|
||
|
.TP
|
||
|
.B \-fsave\-memoized
|
||
|
These flags are used to get the compiler to compile programs faster
|
||
|
using heuristics. They are not on by default since they are only effective
|
||
|
about half the time. The other half of the time programs compile more
|
||
|
slowly (and take more memory).
|
||
|
|
||
|
The first time the compiler must build a call to a member function (or
|
||
|
reference to a data member), it must (1) determine whether the class
|
||
|
implements member functions of that name; (2) resolve which member
|
||
|
function to call (which involves figuring out what sorts of type
|
||
|
conversions need to be made); and (3) check the visibility of the member
|
||
|
function to the caller. All of this adds up to slower compilation.
|
||
|
Normally, the second time a call is made to that member function (or
|
||
|
reference to that data member), it must go through the same lengthy
|
||
|
process again. This means that code like this
|
||
|
.sp
|
||
|
.br
|
||
|
\ \ cout\ <<\ "This\ "\ <<\ p\ <<\ "\ has\ "\ <<\ n\ <<\ "\ legs.\en";
|
||
|
.br
|
||
|
.sp
|
||
|
makes six passes through all three steps. By using a software cache,
|
||
|
a ``hit'' significantly reduces this cost. Unfortunately, using the
|
||
|
cache introduces another layer of mechanisms which must be implemented,
|
||
|
and so incurs its own overhead. `\|\c
|
||
|
.B \-fmemoize\-lookups\c
|
||
|
\&\|' enables
|
||
|
the software cache.
|
||
|
|
||
|
Because access privileges (visibility) to members and member functions
|
||
|
may differ from one function context to the next,
|
||
|
.B g++
|
||
|
may need to flush the cache. With the `\|\c
|
||
|
.B \-fmemoize\-lookups\c
|
||
|
\&\|' flag, the cache is flushed after every
|
||
|
function that is compiled. The `\|\c
|
||
|
\-fsave\-memoized\c
|
||
|
\&\|' flag enables the same software cache, but when the compiler
|
||
|
determines that the context of the last function compiled would yield
|
||
|
the same access privileges of the next function to compile, it
|
||
|
preserves the cache.
|
||
|
This is most helpful when defining many member functions for the same
|
||
|
class: with the exception of member functions which are friends of
|
||
|
other classes, each member function has exactly the same access
|
||
|
privileges as every other, and the cache need not be flushed.
|
||
|
.TP
|
||
|
.B \-fno\-default\-inline
|
||
|
Do not make member functions inline by default merely because they are
|
||
|
defined inside the class scope. Otherwise, when you specify
|
||
|
.B \-O\c
|
||
|
\&, member functions defined inside class scope are compiled
|
||
|
inline by default; i.e., you don't need to add `\|\c
|
||
|
.B inline\c
|
||
|
\&\|' in front of
|
||
|
the member function name.
|
||
|
.TP
|
||
|
.B \-fno\-strict\-prototype
|
||
|
Consider the declaration \c
|
||
|
.B int foo ();\c
|
||
|
\&. In C++, this means that the
|
||
|
function \c
|
||
|
.B foo\c
|
||
|
\& takes no arguments. In ANSI C, this is declared
|
||
|
.B int foo(void);\c
|
||
|
\&. With the flag `\|\c
|
||
|
.B \-fno\-strict\-prototype\c
|
||
|
\&\|',
|
||
|
declaring functions with no arguments is equivalent to declaring its
|
||
|
argument list to be untyped, i.e., \c
|
||
|
.B int foo ();\c
|
||
|
\& is equivalent to
|
||
|
saying \c
|
||
|
.B int foo (...);\c
|
||
|
\&.
|
||
|
.TP
|
||
|
.B \-fnonnull\-objects
|
||
|
Normally, GNU C++ makes conservative assumptions about objects reached
|
||
|
through references. For example, the compiler must check that `\|\c
|
||
|
.B a\c
|
||
|
\&\|' is not null in code like the following:
|
||
|
.br
|
||
|
\ \ \ \ obj\ &a\ =\ g\ ();
|
||
|
.br
|
||
|
\ \ \ \ a.f\ (2);
|
||
|
.br
|
||
|
Checking that references of this sort have non-null values requires
|
||
|
extra code, however, and it is unnecessary for many programs. You can
|
||
|
use `\|\c
|
||
|
.B \-fnonnull\-objects\c
|
||
|
\&\|' to omit the checks for null, if your program doesn't require the
|
||
|
default checking.
|
||
|
.TP
|
||
|
.B \-fhandle\-signatures
|
||
|
.TP
|
||
|
.B \-fno\-handle\-signatures
|
||
|
These options control the recognition of the \c
|
||
|
.B signature\c
|
||
|
\& and \c
|
||
|
.B sigof\c
|
||
|
\& constructs for specifying abstract types. By default, these
|
||
|
constructs are not recognized.
|
||
|
.TP
|
||
|
.B \-fthis\-is\-variable
|
||
|
The incorporation of user-defined free store management into C++ has
|
||
|
made assignment to \c
|
||
|
.B this\c
|
||
|
\& an anachronism. Therefore, by default GNU
|
||
|
C++ treats the type of \c
|
||
|
.B this\c
|
||
|
\& in a member function of \c
|
||
|
.B class X\c
|
||
|
\&
|
||
|
to be \c
|
||
|
.B X *const\c
|
||
|
\&. In other words, it is illegal to assign to
|
||
|
\c
|
||
|
.B this\c
|
||
|
\& within a class member function. However, for backwards
|
||
|
compatibility, you can invoke the old behavior by using
|
||
|
\&`\|\c
|
||
|
.B \-fthis\-is\-variable\c
|
||
|
\&\|'.
|
||
|
.TP
|
||
|
.B \-g
|
||
|
Produce debugging information in the operating system's native format
|
||
|
(for DBX or SDB or DWARF). GDB also can work with this debugging
|
||
|
information. On most systems that use DBX format, `\|\c
|
||
|
.B \-g\c
|
||
|
\&\|' enables use
|
||
|
of extra debugging information that only GDB can use.
|
||
|
|
||
|
Unlike most other C compilers, GNU CC allows you to use `\|\c
|
||
|
.B \-g\c
|
||
|
\&\|' with
|
||
|
`\|\c
|
||
|
.B \-O\c
|
||
|
\&\|'. The shortcuts taken by optimized code may occasionally
|
||
|
produce surprising results: some variables you declared may not exist
|
||
|
at all; flow of control may briefly move where you did not expect it;
|
||
|
some statements may not be executed because they compute constant
|
||
|
results or their values were already at hand; some statements may
|
||
|
execute in different places because they were moved out of loops.
|
||
|
|
||
|
Nevertheless it proves possible to debug optimized output. This makes
|
||
|
it reasonable to use the optimizer for programs that might have bugs.
|
||
|
.TP
|
||
|
.BI "\-I" "dir"\c
|
||
|
\&
|
||
|
Append directory \c
|
||
|
.I dir\c
|
||
|
\& to the list of directories searched for include files.
|
||
|
.TP
|
||
|
.BI "\-L" "dir"\c
|
||
|
\&
|
||
|
Add directory \c
|
||
|
.I dir\c
|
||
|
\& to the list of directories to be searched
|
||
|
for `\|\c
|
||
|
.B \-l\c
|
||
|
\&\|'.
|
||
|
.TP
|
||
|
.BI \-l library\c
|
||
|
\&
|
||
|
Use the library named \c
|
||
|
.I library\c
|
||
|
\& when linking. (C++ programs often require `\|\c
|
||
|
\-lg++\c
|
||
|
\&\|' for successful linking.)
|
||
|
.TP
|
||
|
.B \-nostdinc
|
||
|
Do not search the standard system directories for header files. Only
|
||
|
the directories you have specified with
|
||
|
.B \-I
|
||
|
options (and the current directory, if appropriate) are searched.
|
||
|
.TP
|
||
|
.B \-nostdinc++
|
||
|
Do not search for header files in the standard directories specific to
|
||
|
C++, but do still search the other standard directories. (This option
|
||
|
is used when building libg++.)
|
||
|
.TP
|
||
|
.B \-O
|
||
|
Optimize. Optimizing compilation takes somewhat more time, and a lot
|
||
|
more memory for a large function.
|
||
|
.TP
|
||
|
.BI "\-o " file\c
|
||
|
\&
|
||
|
Place output in file \c
|
||
|
.I file\c
|
||
|
\&.
|
||
|
.TP
|
||
|
.B \-S
|
||
|
Stop after the stage of compilation proper; do not assemble. The output
|
||
|
is an assembler code file for each non-assembler input
|
||
|
file specified.
|
||
|
.TP
|
||
|
.B \-traditional
|
||
|
Attempt to support some aspects of traditional C compilers.
|
||
|
|
||
|
Specifically, for both C and C++ programs:
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
In the preprocessor, comments convert to nothing at all, rather than
|
||
|
to a space. This allows traditional token concatenation.
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
In the preprocessor, macro arguments are recognized within string
|
||
|
constants in a macro definition (and their values are stringified,
|
||
|
though without additional quote marks, when they appear in such a
|
||
|
context). The preprocessor always considers a string constant to end
|
||
|
at a newline.
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
The preprocessor does not predefine the macro \c
|
||
|
.B __STDC__\c
|
||
|
\& when you use
|
||
|
`\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|', but still predefines\c
|
||
|
.B __GNUC__\c
|
||
|
\& (since the GNU extensions indicated by
|
||
|
.B __GNUC__\c
|
||
|
\& are not affected by
|
||
|
`\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|'). If you need to write header files that work
|
||
|
differently depending on whether `\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|' is in use, by
|
||
|
testing both of these predefined macros you can distinguish four
|
||
|
situations: GNU C, traditional GNU C, other ANSI C compilers, and
|
||
|
other old C compilers.
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
In the preprocessor, comments convert to nothing at all, rather than
|
||
|
to a space. This allows traditional token concatenation.
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
In the preprocessor, macro arguments are recognized within string
|
||
|
constants in a macro definition (and their values are stringified,
|
||
|
though without additional quote marks, when they appear in such a
|
||
|
context). The preprocessor always considers a string constant to end
|
||
|
at a newline.
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
The preprocessor does not predefine the macro \c
|
||
|
.B __STDC__\c
|
||
|
\& when you use
|
||
|
`\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|', but still predefines\c
|
||
|
.B __GNUC__\c
|
||
|
\& (since the GNU extensions indicated by
|
||
|
.B __GNUC__\c
|
||
|
\& are not affected by
|
||
|
`\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|'). If you need to write header files that work
|
||
|
differently depending on whether `\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|' is in use, by
|
||
|
testing both of these predefined macros you can distinguish four
|
||
|
situations: GNU C, traditional GNU C, other ANSI C compilers, and
|
||
|
other old C compilers.
|
||
|
.PP
|
||
|
.TP
|
||
|
\ \ \ \(bu
|
||
|
String ``constants'' are not necessarily constant; they are stored in
|
||
|
writable space, and identical looking constants are allocated
|
||
|
separately.
|
||
|
|
||
|
For C++ programs only (not C), `\|\c
|
||
|
.B \-traditional\c
|
||
|
\&\|' has one additional effect: assignment to
|
||
|
.B this
|
||
|
is permitted. This is the same as the effect of `\|\c
|
||
|
.B \-fthis\-is\-variable\c
|
||
|
\&\|'.
|
||
|
.TP
|
||
|
.BI \-U macro
|
||
|
Undefine macro \c
|
||
|
.I macro\c
|
||
|
\&.
|
||
|
.TP
|
||
|
.B \-Wall
|
||
|
Issue warnings for conditions which pertain to usage that we recommend
|
||
|
avoiding and that we believe is easy to avoid, even in conjunction
|
||
|
with macros.
|
||
|
.TP
|
||
|
.B \-Wenum\-clash
|
||
|
Warn when converting between different enumeration types.
|
||
|
.TP
|
||
|
.B \-Woverloaded\-virtual
|
||
|
In a derived class, the definitions of virtual functions must match
|
||
|
the type signature of a virtual function declared in the base class.
|
||
|
Use this option to request warnings when a derived class declares a
|
||
|
function that may be an erroneous attempt to define a virtual
|
||
|
function: that is, warn when a function with the same name as a
|
||
|
virtual function in the base class, but with a type signature that
|
||
|
doesn't match any virtual functions from the base class.
|
||
|
.TP
|
||
|
.B \-Wtemplate\-debugging
|
||
|
When using templates in a C++ program, warn if debugging is not yet
|
||
|
fully available.
|
||
|
.TP
|
||
|
.B \-w
|
||
|
Inhibit all warning messages.
|
||
|
.TP
|
||
|
.BI +e N
|
||
|
Control how virtual function definitions are used, in a fashion
|
||
|
compatible with
|
||
|
.B cfront
|
||
|
1.x.
|
||
|
.PP
|
||
|
|
||
|
.SH PRAGMAS
|
||
|
Two `\|\c
|
||
|
.B #pragma\c
|
||
|
\&\|' directives are supported for GNU C++, to permit using the same
|
||
|
header file for two purposes: as a definition of interfaces to a given
|
||
|
object class, and as the full definition of the contents of that object class.
|
||
|
.TP
|
||
|
.B #pragma interface
|
||
|
Use this directive in header files that define object classes, to save
|
||
|
space in most of the object files that use those classes. Normally,
|
||
|
local copies of certain information (backup copies of inline member
|
||
|
functions, debugging information, and the internal tables that
|
||
|
implement virtual functions) must be kept in each object file that
|
||
|
includes class definitions. You can use this pragma to avoid such
|
||
|
duplication. When a header file containing `\|\c
|
||
|
.B #pragma interface\c
|
||
|
\&\|' is included in a compilation, this auxiliary information
|
||
|
will not be generated (unless the main input source file itself uses
|
||
|
`\|\c
|
||
|
.B #pragma implementation\c
|
||
|
\&\|'). Instead, the object files will contain references to be
|
||
|
resolved at link time.
|
||
|
.tr !"
|
||
|
.TP
|
||
|
.B #pragma implementation
|
||
|
.TP
|
||
|
.BI "#pragma implementation !" objects .h!
|
||
|
Use this pragma in a main input file, when you want full output from
|
||
|
included header files to be generated (and made globally visible).
|
||
|
The included header file, in turn, should use `\|\c
|
||
|
.B #pragma interface\c
|
||
|
\&\|'.
|
||
|
Backup copies of inline member functions, debugging information, and
|
||
|
the internal tables used to implement virtual functions are all
|
||
|
generated in implementation files.
|
||
|
|
||
|
If you use `\|\c
|
||
|
.B #pragma implementation\c
|
||
|
\&\|' with no argument, it applies to an include file with the same
|
||
|
basename as your source file; for example, in `\|\c
|
||
|
.B allclass.cc\c
|
||
|
\&\|', `\|\c
|
||
|
.B #pragma implementation\c
|
||
|
\&\|' by itself is equivalent to `\|\c
|
||
|
.B
|
||
|
#pragma implementation "allclass.h"\c
|
||
|
\&\|'. Use the string argument if you want a single implementation
|
||
|
file to include code from multiple header files.
|
||
|
|
||
|
There is no way to split up the contents of a single header file into
|
||
|
multiple implementation files.
|
||
|
.SH FILES
|
||
|
.ta \w'LIBDIR/g++\-include 'u
|
||
|
file.h C header (preprocessor) file
|
||
|
.br
|
||
|
file.i preprocessed C source file
|
||
|
.br
|
||
|
file.C C++ source file
|
||
|
.br
|
||
|
file.cc C++ source file
|
||
|
.br
|
||
|
file.cxx C++ source file
|
||
|
.br
|
||
|
file.s assembly language file
|
||
|
.br
|
||
|
file.o object file
|
||
|
.br
|
||
|
a.out link edited output
|
||
|
.br
|
||
|
\fITMPDIR\fR/cc\(** temporary files
|
||
|
.br
|
||
|
\fILIBDIR\fR/cpp preprocessor
|
||
|
.br
|
||
|
\fILIBDIR\fR/cc1plus compiler
|
||
|
.br
|
||
|
\fILIBDIR\fR/collect linker front end needed on some machines
|
||
|
.br
|
||
|
\fILIBDIR\fR/libgcc.a GCC subroutine library
|
||
|
.br
|
||
|
/lib/crt[01n].o start-up routine
|
||
|
.br
|
||
|
\fILIBDIR\fR/ccrt0 additional start-up routine for C++
|
||
|
.br
|
||
|
/lib/libc.a standard C library, see
|
||
|
.IR intro (3)
|
||
|
.br
|
||
|
/usr/include standard directory for
|
||
|
.B #include
|
||
|
files
|
||
|
.br
|
||
|
\fILIBDIR\fR/include standard gcc directory for
|
||
|
.B #include
|
||
|
files
|
||
|
.br
|
||
|
\fILIBDIR\fR/g++\-include additional g++ directory for
|
||
|
.B #include
|
||
|
.sp
|
||
|
.I LIBDIR
|
||
|
is usually
|
||
|
.B /usr/local/lib/\c
|
||
|
.IR machine / version .
|
||
|
.br
|
||
|
.I TMPDIR
|
||
|
comes from the environment variable
|
||
|
.B TMPDIR
|
||
|
(default
|
||
|
.B /usr/tmp
|
||
|
if available, else
|
||
|
.B /tmp\c
|
||
|
\&).
|
||
|
.SH "SEE ALSO"
|
||
|
gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1).
|
||
|
.br
|
||
|
.RB "`\|" gcc "\|', `\|" cpp \|',
|
||
|
.RB `\| as \|', `\| ld \|',
|
||
|
and
|
||
|
.RB `\| gdb \|'
|
||
|
entries in
|
||
|
.B info\c
|
||
|
\&.
|
||
|
.br
|
||
|
.I
|
||
|
Using and Porting GNU CC (for version 2.0)\c
|
||
|
, Richard M. Stallman;
|
||
|
.I
|
||
|
The C Preprocessor\c
|
||
|
, Richard M. Stallman;
|
||
|
.I
|
||
|
Debugging with GDB: the GNU Source-Level Debugger\c
|
||
|
, Richard M. Stallman and Roland H. Pesch;
|
||
|
.I
|
||
|
Using as: the GNU Assembler\c
|
||
|
, Dean Elsner, Jay Fenlason & friends;
|
||
|
.I
|
||
|
gld: the GNU linker\c
|
||
|
, Steve Chamberlain and Roland Pesch.
|
||
|
|
||
|
.SH BUGS
|
||
|
For instructions on how to report bugs, see the GCC manual.
|
||
|
|
||
|
.SH COPYING
|
||
|
Copyright (c) 1991, 1992, 1993 Free Software Foundation, Inc.
|
||
|
.PP
|
||
|
Permission is granted to make and distribute verbatim copies of
|
||
|
this manual provided the copyright notice and this permission notice
|
||
|
are preserved on all copies.
|
||
|
.PP
|
||
|
Permission is granted to copy and distribute modified versions of this
|
||
|
manual under the conditions for verbatim copying, provided that the
|
||
|
entire resulting derived work is distributed under the terms of a
|
||
|
permission notice identical to this one.
|
||
|
.PP
|
||
|
Permission is granted to copy and distribute translations of this
|
||
|
manual into another language, under the above conditions for modified
|
||
|
versions, except that this permission notice may be included in
|
||
|
translations approved by the Free Software Foundation instead of in
|
||
|
the original English.
|
||
|
.SH AUTHORS
|
||
|
See the GNU CC Manual for the contributors to GNU CC.
|