g77install.texi

gcc-2.95.3 Linux下最常用的C编译器

@xref{Building gcc}, for complete @code{g77}-specific
information on this step.

@item Step @value{compare-gcc}: @kbd{make compare}
@xref{Bug Lists,,Where to Port Bugs}, for information
on where to report that you observed files
having different contents during this
phase.

@xref{Bug Reporting,,How to Report Bugs}, for
information on @emph{how} to report bugs like this.

@item Step @value{rm-stage1}: @kbd{rm -fr stage1}
You don't need to do this, but it frees up disk space.

@item Step @value{install-g77}: @kbd{make -k install}
If this doesn't seem to work, try:

@example
make -k install install-libf77
@end example

Or, make sure you're using GNU @code{make}.

@xref{Installation of Binaries}, for more information.

@xref{Updating Documentation,,Updating Your Info Directory},
for information on entering this manual into your
system's list of texinfo manuals.

@item Step @value{show-version}: @kbd{g77 -v}
If this command prints approximately 25 lines of output,
including the GNU Fortran Front End version number (which
should be the same as the version number for the version
of @code{g77} you just built and installed) and the
version numbers for the three parts of the @code{libf2c}
library (@code{libF77}, @code{libI77}, @code{libU77}), and
those version numbers are all in agreement, then there is
a high likelihood that the installation has been successfully
completed.

You might consider doing further testing.
For example, log in as a non-privileged user, then create
a small Fortran program, such as:

@example
      PROGRAM SMTEST
      DO 10 I=1, 10
         PRINT *, 'Hello World #', I
10    CONTINUE
      END
@end example

Compile, link, and run the above program, and, assuming you named
the source file @file{smtest.f}, the session should look like this:

@example
sh# @kbd{g77 -o smtest smtest.f}
sh# @kbd{./smtest}
 Hello World # 1
 Hello World # 2
 Hello World # 3
 Hello World # 4
 Hello World # 5
 Hello World # 6
 Hello World # 7
 Hello World # 8
 Hello World # 9
 Hello World # 10
sh#
@end example

If invoking @code{g77} doesn't seem to work,
the problem might be that you've installed it in
a location that is not in your shell's search path.
For example, if you specified @samp{--prefix=/gnu},
and @file{/gnu/bin} is not in your @code{PATH}
environment variable,
you must explicitly specify the location of the compiler
via @kbd{/gnu/bin/g77 -o smtest smtest.f}.

After proper installation, you don't
need to keep your gcc and g77 source and build directories
around anymore.
Removing them can free up a lot of disk space.
@end table

@end ifclear

@node Complete Installation
@section Complete Installation

@ifset OMIT-FSF-G77
For users of the @value{which-g77} version of @code{g77},
this information is superceded by the
@value{which-gcc} installation instructions.
@end ifset

@ifclear OMIT-FSF-G77
Here is the complete @code{g77}-specific information on how
to configure, build, and install @code{g77}.

@menu
* Unpacking::
* Merging Distributions::
* Where to Install::
* Configuring gcc::
* Building gcc::
* Pre-installation Checks::
* Installation of Binaries::
* Updating Documentation::
* Missing tools?::
@end menu

@node Unpacking
@subsection Unpacking
@cindex unpacking distributions
@cindex distributions, unpacking
@cindex code, source
@cindex source code
@cindex source tree
@cindex packages

The @code{gcc} source distribution is a stand-alone distribution.
It is designed to be unpacked (producing the @code{gcc}
source tree) and built as is, assuming certain
prerequisites are met (including the availability of compatible
UNIX programs such as @code{make}, @code{cc}, and so on).

However, before building @code{gcc}, you will want to unpack
and merge the @code{g77} distribution in with it, so that you
build a Fortran-capable version of @code{gcc}, which includes
the @code{g77} command, the necessary run-time libraries,
and this manual.

Unlike @code{gcc}, the @code{g77} source distribution
is @emph{not} a stand-alone distribution.
It is designed to be unpacked and, afterwards, immediately merged
into an applicable @code{gcc} source tree.
That is, the @code{g77} distribution @emph{augments} a
@code{gcc} distribution---without @code{gcc}, generally
only the documentation is immediately usable.

A sequence of commands typically used to unpack @code{gcc}
and @code{g77} is:

@example
sh# @kbd{cd /usr/src}
sh# @kbd{gunzip -c /usr/FSF/gcc-@value{version-gcc}.tar.gz | tar xf -}
sh# @kbd{gunzip -c /usr/FSF/g77-@value{version-g77}.tar.gz | tar xf -}
sh# @kbd{ln -s gcc-@value{version-gcc} gcc}
sh# @kbd{ln -s g77-@value{version-g77} g77}
sh# @kbd{mv -i g77/* gcc}
@end example

@emph{Notes:} The commands beginning with @samp{gunzip@dots{}} might
print @samp{Broken pipe@dots{}} as they complete.
That is nothing to worry about, unless you actually
@emph{hear} a pipe breaking.
The @code{ln} commands are helpful in reducing typing
and clutter in installation examples in this manual.
Hereafter, the top level of @code{gcc} source tree is referred to
as @file{gcc}, and the top level of just the @code{g77}
source tree (prior to issuing the @code{mv} command, above)
is referred to as @file{g77}.

There are three top-level names in a @code{g77} distribution:

@example
g77/COPYING.g77
g77/README.g77
g77/f
@end example

All three entries should be moved (or copied) into a @code{gcc}
source tree (typically named after its version number and
as it appears in the FSF distributions---e.g. @file{gcc-@value{version-gcc}}).

@file{g77/f} is the subdirectory containing all of the
code, documentation, and other information that is specific
to @code{g77}.
The other two files exist to provide information on @code{g77}
to someone encountering a @code{gcc} source tree with @code{g77}
already present, who has not yet read these installation
instructions and thus needs help understanding that the
source tree they are looking at does not come from a single
FSF distribution.
They also help people encountering an unmerged @code{g77} source
tree for the first time.

@cindex modifying @code{g77}
@cindex code, modifying
@cindex Pentium optimizations
@cindex optimization, for Pentium
@emph{Note:} Please use @strong{only} @code{gcc} and @code{g77}
source trees as distributed by the FSF.
Use of modified versions is likely to result in problems that appear to be
in the @code{g77} code but, in fact, are not.
Do not use such modified versions
unless you understand all the differences between them and the versions
the FSF distributes---in which case you should be able to modify the
@code{g77} (or @code{gcc}) source trees appropriately so @code{g77}
and @code{gcc} can coexist as they do in the stock FSF distributions.

@node Merging Distributions
@subsection Merging Distributions
@cindex merging distributions
@cindex @code{gcc}, versions supported by @code{g77}
@cindex versions, of @code{gcc}
@cindex support, @code{gcc} versions

After merging the @code{g77} source tree into the @code{gcc} source tree,
you have put together a complete @code{g77} source tree.

@cindex @code{gcc}, version number
@cindex version number
@cindex @code{g77}, version number
@cindex GNU version numbering
As of version 0.5.23, @code{g77} no longer modifies
the version number of @code{gcc},
nor does it patch @code{gcc} itself.

@code{g77} still depends on being merged with an
appropriate version of @code{gcc}.
For version @value{version-g77} of @code{g77},
the specific version of @code{gcc} supported is @value{version-gcc}.

However, other versions of @code{gcc} might be suitable
``hosts'' for this version of @code{g77}.

GNU version numbers make it easy to figure out whether a
particular version of a distribution is newer or older than
some other version of that distribution.
The format is,
generally, @var{major}.@var{minor}.@var{patch}, with
each field being a decimal number.
(You can safely ignore
leading zeros; for example, 1.5.3 is the same as 1.5.03.)
The @var{major} field only increases with time.
The other two fields are reset to 0 when the field to
their left is incremented; otherwise, they, too, only
increase with time.
So, version 2.6.2 is newer than version 2.5.8, and
version 3.0 is newer than both.
(Trailing @samp{.0} fields often are omitted in
announcements and in names for distributions and
the directories they create.)

If your version of @code{gcc} is older than the oldest version
supported by @code{g77}
(as casually determined by listing the contents of @file{@value{path-g77}/INSTALL/},
which contains these installation instructions in plain-text format),
you should obtain a newer, supported version of @code{gcc}.
(You could instead obtain an older version of @code{g77},
or try and get your @code{g77} to work with the old
@code{gcc}, but neither approach is recommended, and
you shouldn't bother reporting any bugs you find if you
take either approach, because they're probably already
fixed in the newer versions you're not using.)

If your version of @code{gcc} is newer than the newest version
supported by @code{g77}, it is possible that your @code{g77}
will work with it anyway.
If the version number for @code{gcc} differs only in the
@var{patch} field, you might as well try that version of @code{gcc}.
Since it has the same @var{major} and @var{minor} fields,
the resulting combination is likely to work.

So, for example, if a particular version of @code{g77} has support for
@code{gcc} versions 2.8.0 and 2.8.1,
it is likely that @file{gcc-2.8.2} would work well with @code{g77}.

However, @file{gcc-2.9.0} would almost certainly
not work with that version of @code{g77}
without appropriate modifications,
so a new version of @code{g77} would be needed.

@cindex distributions, why separate
@cindex separate distributions
@cindex why separate distributions
This complexity is the result of @code{gcc} and @code{g77} being
separate distributions.
By keeping them separate, each product is able to be independently
improved and distributed to its user base more frequently.

However, the GBE interface defined by @code{gcc} typically
undergoes some incompatible changes at least every time the
@var{minor} field of the version number is incremented,
and such changes require corresponding changes to
the @code{g77} front end (FFE).

@c @pindex config-lang.in
@c @emph{Note:} @code{g77}'s configuration file @file{@value{path-g77}/config-lang.in}
@c sometimes ensures that the source code for the version of @code{gcc}
@c being configured has at least one indication of being an appropriate
@c version as required specifically by @code{g77}.
@c This configuration-time
@c checking should catch failures to use the proper version of @code{gcc} and,
@c if so caught, should abort the configuration with an explanation.
@c @emph{Please} do not try to disable this check,
@c otherwise @code{g77} might well appear to build
@c and install correctly, and even appear to compile correctly,
@c but could easily produce broken code.

@node Where to Install
@subsection Where in the World Does Fortran (and GNU CC) Go?
@cindex language f77 not recognized
@cindex @code{gcc}, will not compile Fortran programs

Before configuring, you should make sure you know
where you want the @code{g77} and @code{gcc}
binaries to be installed after they're built,
because this information is given to the configuration
tool and used during the build itself.

A @code{g77} installation normally includes installation of
a Fortran-aware version of @code{gcc}, so that the @code{gcc}
command recognizes Fortran source files and knows how to compile
them.

For this to work, the version of @code{gcc} that you will be building
as part of @code{g77} @strong{must} be installed as the ``active''
version of @code{gcc} on the system.

Sometimes people make the mistake of installing @code{gcc} as
@file{/usr/local/bin/gcc},
leaving an older, non-Fortran-aware version in @file{/usr/bin/gcc}.
(Or, the opposite happens.)
This can result in @code{gcc} being unable to compile Fortran
source files,
because when the older version of @code{gcc} is invoked,
it complains that it does not
recognize the language, or the file name suffix.

So, determine whether @code{gcc} already is installed on your system,
and, if so, @emph{where} it is installed, and prepare to configure the
new version of @code{gcc} you'll be building so that it installs
over the existing version of @code{gcc}.

You might want to back up your existing copy of @file{/usr/bin/gcc}, and
the entire @file{/usr/lib} directory, before
you perform the actual installation (as described in this manual).

Existing @code{gcc} installations typically are
found in @file{/usr} or @file{/usr/local}.
(This means the commands are installed in @file{/usr/bin} or
@file{/usr/local/bin},
the libraries in @file{/usr/lib} or @file{/usr/local/lib},
and so on.)

If you aren't certain where the currently
installed version of @code{gcc} and its
related programs reside, look at the output
of this command:

@example
gcc -v -o /tmp/delete-me -xc /dev/null -xnone
@end example

All sorts of interesting information on the locations of various
@code{gcc}-related programs and data files should be visible
in the output of the above command.