Initial revision

[gcc.git] / gcc / f / INSTALL

This file contains installation information for the GNU Fortran
compiler.  Copyright (C) 1995, 1996 Free Software Foundation, Inc.  You
may copy, distribute, and modify it freely as long as you preserve this
copyright notice and permission notice.

Installing GNU Fortran
**********************

   The following information describes how to install `g77'.

   The information in this file generally pertains to dealing with
*source* distributions of `g77' and `gcc'.  It is possible that some of
this information will be applicable to some *binary* distributions of
these products--however, since these distributions are not made by the
maintainers of `g77', responsibility for binary distributions rests with
whoever built and first distributed them.

   Nevertheless, efforts to make `g77' easier to both build and install
from source and package up as a binary distribution are ongoing.

Prerequisites
=============

   The procedures described to unpack, configure, build, and install
`g77' assume your system has certain programs already installed.

   The following prerequisites should be met by your system before you
follow the `g77' installation instructions:

`gzip'
     To unpack the `gcc' and `g77' distributions, you'll need the
     `gunzip' utility in the `gzip' distribution.  Most UNIX systems
     already have `gzip' installed.  If yours doesn't, you can get it
     from the FSF.

     Note that you'll need `tar' and other utilities as well, but all
     UNIX systems have these.  There are GNU versions of all these
     available--in fact, a complete GNU UNIX system can be put together
     on most systems, if desired.

`gcc-2.7.2.2.tar.gz'
     You need to have this, or some other applicable, version of `gcc'
     on your system.  The version should be an exact copy of a
     distribution from the FSF.  It is approximately 7MB large.

     If you've already unpacked `gcc-2.7.2.2.tar.gz' into a directory
     (named `gcc-2.7.2.2') called the "source tree" for `gcc', you can
     delete the distribution itself, but you'll need to remember to
     skip any instructions to unpack this distribution.

     Without an applicable `gcc' source tree, you cannot build `g77'.
     You can obtain an FSF distribution of `gcc' from the FSF.

`g77-0.5.21.tar.gz'
     You probably have already unpacked this distribution, or you are
     reading an advanced copy of this manual, which is contained in
     this distribution.  This distribution approximately 1MB large.

     You can obtain an FSF distribution of `g77' from the FSF, the same
     way you obtained `gcc'.

100MB disk space
     For a complete "bootstrap" build, about 100MB of disk space is
     required for `g77' by the author's current GNU/Linux system.

     Some juggling can reduce the amount of space needed; during the
     bootstrap process, once Stage 3 starts, during which the version
     of `gcc' that has been copied into the `stage2/' directory is used
     to rebuild the system, you can delete the `stage1/' directory to
     free up some space.

     It is likely that many systems don't require the complete
     bootstrap build, as they already have a recent version of `gcc'
     installed.  Such systems might be able to build `g77' with only
     about 75MB of free space.

`patch'
     Although you can do everything `patch' does yourself, by hand,
     without much trouble, having `patch' installed makes installation
     of new versions of GNU utilities such as `g77' so much easier that
     it is worth getting.  You can obtain `patch' the same way you
     obtained `gcc' and `g77'.

     In any case, you can apply patches by hand--patch files are
     designed for humans to read them.

`make'
     Your system must have `make', and you will probably save yourself
     a lot of trouble if it is GNU `make' (sometimes referred to as
     `gmake').

`cc'
     Your system must have a working C compiler.

     *Note Installing GNU CC: (gcc)Installation, for more information
     on prerequisites for installing `gcc'.

`bison'
     If you do not have `bison' installed, you can usually work around
     any need for it, since `g77' itself does not use it, and `gcc'
     normally includes all files generated by running it in its
     distribution.  You can obtain `bison' the same way you obtained
     `gcc' and `g77'.

     *Note Missing bison?::, for information on how to work around not
     having `bison'.

`makeinfo'
     If you are missing `makeinfo', you can usually work around any
     need for it.  You can obtain `makeinfo' the same way you obtained
     `gcc' and `g77'.

     *Note Missing makeinfo?::, for information on getting around the
     lack of `makeinfo'.

`root' access
     To perform the complete installation procedures on a system, you
     need to have `root' access to that system, or equivalent access.

     Portions of the procedure (such as configuring and building `g77')
     can be performed by any user with enough disk space and virtual
     memory.

     However, these instructions are oriented towards less-experienced
     users who want to install `g77' on their own personal systems.

     System administrators with more experience will want to determine
     for themselves how they want to modify the procedures described
     below to suit the needs of their installation.

Problems Installing
===================

   This is a list of problems (and some apparent problems which don't
really mean anything is wrong) that show up when configuring, building,
installing, or porting GNU Fortran.

   *Note Installation Problems: (gcc)Installation Problems, for more
information on installation problems that can afflict either `gcc' or
`g77'.

General Problems
----------------

   These problems can occur on most or all systems.

GNU C Required
..............

   Compiling `g77' requires GNU C, not just ANSI C.  Fixing this
wouldn't be very hard (just tedious), but the code using GNU extensions
to the C language is expected to be rewritten for 0.6 anyway, so there
are no plans for an interim fix.

   This requirement does not mean you must already have `gcc' installed
to build `g77'.  As long as you have a working C compiler, you can use a
bootstrap build to automate the process of first building `gcc' using
the working C compiler you have, then building `g77' and rebuilding
`gcc' using that just-built `gcc', and so on.

Patching GNU CC Necessary
.........................

   `g77' currently requires application of a patch file to the gcc
compiler tree.  The necessary patches should be folded in to the
mainline gcc distribution.

   Some combinations of versions of `g77' and `gcc' might actually
*require* no patches, but the patch files will be provided anyway as
long as there are more changes expected in subsequent releases.  These
patch files might contain unnecessary, but possibly helpful, patches.
As a result, it is possible this issue might never be resolved, except
by eliminating the need for the person configuring `g77' to apply a
patch by hand, by going to a more automated approach (such as
configure-time patching).

Building GNU CC Necessary
.........................

   It should be possible to build the runtime without building `cc1'
and other non-Fortran items, but, for now, an easy way to do that is
not yet established.

Missing strtoul
...............

   On SunOS4 systems, linking the `f771' program produces an error
message concerning an undefined symbol named `_strtoul'.

   This is not a `g77' bug.  *Note Patching GNU Fortran::, for
information on a workaround provided by `g77'.

   The proper fix is either to upgrade your system to one that provides
a complete ANSI C environment, or improve `gcc' so that it provides one
for all the languages and configurations it supports.

   *Note:* In earlier versions of `g77', an automated workaround for
this problem was attempted.  It worked for systems without `_strtoul',
substituting the incomplete-yet-sufficient version supplied with `g77'
for those systems.  However, the automated workaround failed
mysteriously for systems that appeared to have conforming ANSI C
environments, and it was decided that, lacking resources to more fully
investigate the problem, it was better to not punish users of those
systems either by requiring them to work around the problem by hand or
by always substituting an incomplete `strtoul()' implementation when
their systems had a complete, working one.  Unfortunately, this meant
inconveniencing users of systems not having `strtoul()', but they're
using obsolete (and generally unsupported) systems anyway.

Object File Differences
.......................

   A comparison of object files after building Stage 3 during a
bootstrap build will result in `gcc/f/zzz.o' being flagged as different
from the Stage 2 version.  That is because it contains a string with an
expansion of the `__TIME__' macro, which expands to the current time of
day.  It is nothing to worry about, since `gcc/f/zzz.c' doesn't contain
any actual code.  It does allow you to override its use of `__DATE__'
and `__TIME__' by defining macros for the compilation--see the source
code for details.

Cleanup Kills Stage Directories
...............................

   It'd be helpful if `g77''s `Makefile.in' or `Make-lang.in' would
create the various `stageN' directories and their subdirectories, so
developers and expert installers wouldn't have to reconfigure after
cleaning up.

Missing `gperf'?
................

   If a build aborts trying to invoke `gperf', that strongly suggests
an improper method was used to create the `gcc' source directory, such
as the UNIX `cp -r' command instead of `cp -pr', since this problem
very likely indicates that the date-time-modified information on the
`gcc' source files is incorrect.

   The proper solution is to recreate the `gcc' source directory from a
`gcc' distribution known to be provided by the FSF.

   It is possible you might be able to temporarily work around the
problem, however, by trying these commands:

     sh# cd gcc
     sh# touch c-gperf.h
     sh#

   These commands update the date-time-modified information for the
file produced by the invocation of `gperf' in the current versions of
`gcc', so that `make' no longer believes it needs to update it.  This
file should already exist in a `gcc' distribution, but mistakes made
when copying the `gcc' directory can leave the modification information
set such that the `gperf' input files look more "recent" than the
corresponding output files.

   If the above does not work, definitely start from scratch and avoid
copying the `gcc' using any method that does not reliably preserve
date-time-modified information, such as the UNIX `cp -r' command.

Cross-compiler Problems
-----------------------

   `g77' has been in alpha testing since September of 1992, and in
public beta testing since February of 1995.  Alpha testing was done by
a small number of people worldwide on a fairly wide variety of
machines, involving self-compilation in most or all cases.  Beta
testing has been done primarily via self-compilation, but in more and
more cases, cross-compilation (and "criss-cross compilation", where a
version of a compiler is built on one machine to run on a second and
generate code that runs on a third) has been tried and has succeeded,
to varying extents.

   Generally, `g77' can be ported to any configuration to which `gcc',
`f2c', and `libf2c' can be ported and made to work together, aside from
the known problems described in this manual.  If you want to port `g77'
to a particular configuration, you should first make sure `gcc' and
`libf2c' can be ported to that configuration before focusing on `g77',
because `g77' is so dependent on them.

   Even for cases where `gcc' and `libf2c' work, you might run into
problems with cross-compilation on certain machines, for several
reasons.

   * There is one known bug (a design bug to be fixed in 0.6) that
     prevents configuration of `g77' as a cross-compiler in some cases,
     though there are assumptions made during configuration that
     probably make doing non-self-hosting builds a hassle, requiring
     manual intervention.

   * `gcc' might still have some trouble being configured for certain
     combinations of machines.  For example, it might not know how to
     handle floating-point constants.

   * Improvements to the way `libf2c' is built could make building
     `g77' as a cross-compiler easier--for example, passing and using
     `LD' and `AR' in the appropriate ways.

   * There are still some challenges putting together the right
     run-time libraries (needed by `libf2c') for a target system,
     depending on the systems involved in the configuration.  (This is
     a general problem with cross-compilation, and with `gcc' in
     particular.)

Changing Settings Before Building
=================================

   Here are some internal `g77' settings that can be changed by editing
source files in `gcc/f/' before building.

   This information, and perhaps even these settings, represent
stop-gap solutions to problems people doing various ports of `g77' have
encountered.  As such, none of the following information is expected to
be pertinent in future versions of `g77'.

Larger File Unit Numbers
------------------------

   As distributed, whether as part of `f2c' or `g77', `libf2c' accepts
file unit numbers only in the range 0 through 99.  For example, a
statement such as `WRITE (UNIT=100)' causes a run-time crash in
`libf2c', because the unit number, 100, is out of range.

   If you know that Fortran programs at your installation require the
use of unit numbers higher than 99, you can change the value of the
`MXUNIT' macro, which represents the maximum unit number, to an
appropriately higher value.

   To do this, edit the file `f/runtime/libI77/fio.h' in your `g77'
source tree, changing the following line:

     #define MXUNIT 100

   Change the line so that the value of `MXUNIT' is defined to be at
least one *greater* than the maximum unit number used by the Fortran
programs on your system.

   (For example, a program that does `WRITE (UNIT=255)' would require
`MXUNIT' set to at least 256 to avoid crashing.)

   Then build or rebuild `g77' as appropriate.

   *Note:* Changing this macro has *no* effect on other limits your
system might place on the number of files open at the same time.  That
is, the macro might allow a program to do `WRITE (UNIT=100)', but the
library and operating system underlying `libf2c' might disallow it if
many other files have already been opened (via `OPEN' or implicitly via
`READ', `WRITE', and so on).  Information on how to increase these
other limits should be found in your system's documentation.

Always Flush Output
-------------------

   Some Fortran programs require output (writes) to be flushed to the
operating system (under UNIX, via the `fflush()' library call) so that
errors, such as disk full, are immediately flagged via the relevant
`ERR=' and `IOSTAT=' mechanism, instead of such errors being flagged
later as subsequent writes occur, forcing the previously written data
to disk, or when the file is closed.

   Essentially, the difference can be viewed as synchronous error
reporting (immediate flagging of errors during writes) versus
asynchronous, or, more precisely, buffered error reporting (detection
of errors might be delayed).

   `libf2c' supports flagging write errors immediately when it is built
with the `ALWAYS_FLUSH' macro defined.  This results in a `libf2c' that
runs slower, sometimes quite a bit slower, under certain
circumstances--for example, accessing files via the networked file
system NFS--but the effect can be more reliable, robust file I/O.

   If you know that Fortran programs requiring this level of precision
of error reporting are to be compiled using the version of `g77' you
are building, you might wish to modify the `g77' source tree so that
the version of `libf2c' is built with the `ALWAYS_FLUSH' macro defined,
enabling this behavior.

   To do this, find this line in `f/runtime/configure.in' in your `g77'
source tree:

     dnl AC_DEFINE(ALWAYS_FLUSH)

   Remove the leading `dnl ', so the line begins with `AC_DEFINE(', and
run `autoconf' in that file's directory.  (Or, if you don't have
`autoconf', you can modify `f2c.h.in' in the same directory to include
the line `#define ALWAYS_FLUSH' after `#define F2C_INCLUDE'.)

   Then build or rebuild `g77' as appropriate.

Maximum Stackable Size
----------------------

   `g77', on most machines, puts many variables and arrays on the stack
where possible, and can be configured (by changing
`FFECOM_sizeMAXSTACKITEM' in `gcc/f/com.c') to force smaller-sized
entities into static storage (saving on stack space) or permit
larger-sized entities to be put on the stack (which can improve
run-time performance, as it presents more opportunities for the GBE to
optimize the generated code).

   *Note:* Putting more variables and arrays on the stack might cause
problems due to system-dependent limits on stack size.  Also, the value
of `FFECOM_sizeMAXSTACKITEM' has no effect on automatic variables and
arrays.  *Note But-bugs::, for more information.

Floating-point Bit Patterns
---------------------------

   The `g77' build will crash if an attempt is made to build it as a
cross-compiler for a target when `g77' cannot reliably determine the
bit pattern of floating-point constants for the target.  Planned
improvements for g77-0.6 will give it the capabilities it needs to not
have to crash the build but rather generate correct code for the target.
(Currently, `g77' would generate bad code under such circumstances if
it didn't crash during the build, e.g. when compiling a source file
that does something like `EQUIVALENCE (I,R)' and `DATA R/9.43578/'.)

Initialization of Large Aggregate Areas
---------------------------------------

   A warning message is issued when `g77' sees code that provides
initial values (e.g. via `DATA') to an aggregate area (`COMMON' or
`EQUIVALENCE', or even a large enough array or `CHARACTER' variable)
that is large enough to increase `g77''s compile time by roughly a
factor of 10.

   This size currently is quite small, since `g77' currently has a
known bug requiring too much memory and time to handle such cases.  In
`gcc/f/data.c', the macro `FFEDATA_sizeTOO_BIG_INIT_' is defined to the
minimum size for the warning to appear.  The size is specified in
storage units, which can be bytes, words, or whatever, on a
case-by-case basis.

   After changing this macro definition, you must (of course) rebuild
and reinstall `g77' for the change to take effect.

   Note that, as of version 0.5.18, improvements have reduced the scope
of the problem for *sparse* initialization of large arrays, especially
those with large, contiguous uninitialized areas.  However, the warning
is issued at a point prior to when `g77' knows whether the
initialization is sparse, and delaying the warning could mean it is
produced too late to be helpful.

   Therefore, the macro definition should not be adjusted to reflect
sparse cases.  Instead, adjust it to generate the warning when densely
initialized arrays begin to cause responses noticeably slower than
linear performance would suggest.

Alpha Problems Fixed
--------------------

   `g77' used to warn when it was used to compile Fortran code for a
target configuration that is not basically a 32-bit machine (such as an
Alpha, which is a 64-bit machine, especially if it has a 64-bit
operating system running on it).  That was because `g77' was known to
not work properly on such configurations.

   As of version 0.5.20, `g77' is believed to work well enough on such
systems.  So, the warning is no longer needed or provided.

   However, support for 64-bit systems, especially in areas such as
cross-compilation and handling of intrinsics, is still incomplete.  The
symptoms are believed to be compile-time diagnostics rather than the
generation of bad code.  It is hoped that version 0.6 will completely
support 64-bit systems.

Quick Start
===========

   This procedure configures, builds, and installs `g77' "out of the
box" and works on most UNIX systems.  Each command is identified by a
unique number, used in the explanatory text that follows.  For the most
part, the output of each command is not shown, though indications of
the types of responses are given in a few cases.

   To perform this procedure, the installer must be logged in as user
`root'.  Much of it can be done while not logged in as `root', and
users experienced with UNIX administration should be able to modify the
procedure properly to do so.

   Following traditional UNIX conventions, it is assumed that the
source trees for `g77' and `gcc' will be placed in `/usr/src'.  It also
is assumed that the source distributions themselves already reside in
`/usr/FSF', a naming convention used by the author of `g77' on his own
system:

     /usr/FSF/gcc-2.7.2.2.tar.gz
     /usr/FSF/g77-0.5.21.tar.gz

   Users of the following systems should not blindly follow these
quick-start instructions, because of problems their systems have coping
with straightforward installation of `g77':

   * SunOS4

   Instead, see *Note Complete Installation::, for detailed information
on how to configure, build, and install `g77' for your particular
system.  Also, see *Note Known Causes of Trouble with GNU Fortran:
Trouble, for information on bugs and other problems known to afflict the
installation process, and how to report newly discovered ones.

   If your system is *not* on the above list, and *is* a UNIX system or
one of its variants, you should be able to follow the instructions
below.  If you vary *any* of the steps below, you might run into
trouble, including possibly breaking existing programs for other users
of your system.  Before doing so, it is wise to review the explanations
of some of the steps.  These explanations follow this list of steps.

     sh[ 1]# cd /usr/src
     
     sh[ 2]# gunzip -c < /usr/FSF/gcc-2.7.2.2.tar.gz | tar xf -
     [Might say "Broken pipe"...that is normal on some systems.]
     
     sh[ 3]# gunzip -c < /usr/FSF/g77-0.5.21.tar.gz | tar xf -
     ["Broken pipe" again possible.]
     
     sh[ 4]# ln -s gcc-2.7.2.2 gcc
     
     sh[ 5]# ln -s g77-0.5.21 g77
     
     sh[ 6]# mv -i g77/* gcc
     [No questions should be asked by mv here; or, you made a mistake.]
     
     sh[ 7]# patch -p1 -V t -d gcc < gcc/f/gbe/2.7.2.2.diff
     [Unless patch complains about rejected patches, this step worked.]
     
     sh[ 8]# cd gcc
     sh[ 9]# touch f77-install-ok
     [Do not do the above if your system already has an f77
     command, unless you've checked that overwriting it
     is okay.]
     
     sh[10]# touch f2c-install-ok
     [Do not do the above if your system already has an f2c
     command, unless you've checked that overwriting it
     is okay.  Else, touch f2c-exists-ok.]
     
     sh[11]# ./configure --prefix=/usr
     [Do not do the above if gcc is not installed in /usr/bin.
     You might need a different --prefix=..., as
     described below.]
     
     sh[12]# make bootstrap
     [This takes a long time, and is where most problems occur.]
     
     sh[13]# rm -fr stage1
     
     sh[14]# make -k install
     [The actual installation.]
     
     sh[15]# g77 -v
     [Verify that g77 is installed, obtain version info.]
     
     sh[16]#

   *Note Updating Your Info Directory: Updating Documentation, for
information on how to update your system's top-level `info' directory
to contain a reference to this manual, so that users of `g77' can
easily find documentation instead of having to ask you for it.

   Elaborations of many of the above steps follows:

Step 1: `cd /usr/src'
     You can build `g77' pretty much anyplace.  By convention, this
     manual assumes `/usr/src'.  It might be helpful if other users on
     your system knew where to look for the source code for the
     installed version of `g77' and `gcc' in any case.

Step 3: `gunzip -d < /usr/FSF/g77-0.5.21.tar.gz | tar xf -'
     It is not always necessary to obtain the latest version of `g77'
     as a complete `.tar.gz' file if you have a complete, earlier
     distribution of `g77'.  If appropriate, you can unpack that earlier
     version of `g77', and then apply the appropriate patches to
     achieve the same result--a source tree containing version 0.5.21
     of `g77'.

Step 4: `ln -s gcc-2.7.2.2 gcc'

Step 5: `ln -s g77-0.5.21 g77'
     These commands mainly help reduce typing, and help reduce visual
     clutter in examples in this manual showing what to type to install
     `g77'.

     *Note Unpacking::, for information on using distributions of `g77'
     made by organizations other than the FSF.

Step 6: `mv -i g77/* gcc'
     After doing this, you can, if you like, type `rm g77' and `rmdir
     g77-0.5.21' to remove the empty directory and the symbol link to
     it.  But, it might be helpful to leave them around as quick
     reminders of which version(s) of `g77' are installed on your
     system.

     *Note Unpacking::, for information on the contents of the `g77'
     directory (as merged into the `gcc' directory).

Step 7: `patch -p1 ...'
     This can produce a wide variety of printed output, from `Hmm, I
     can't seem to find a patch in there anywhere...'  to long lists of
     messages indicated that patches are being found, applied
     successfully, and so on.

     If messages about "fuzz", "offset", or especially "reject files"
     are printed, it might mean you applied the wrong patch file.  If
     you believe this is the case, it is best to restart the sequence
     after deleting (or at least renaming to unused names) the
     top-level directories for `g77' and `gcc' and their symbolic links.

     After this command finishes, the `gcc' directory might have old
     versions of several files as saved by `patch'.  To remove these,
     after `cd gcc', type `rm -i *.~*~'.

     *Note Merging Distributions::, for more information.

Step 9: `touch f77-install-ok'
     Don't do this if you don't want to overwrite an existing version
     of `f77' (such as a native compiler, or a script that invokes
     `f2c').  Otherwise, installation will overwrite the `f77' command
     and the `f77' man pages with copies of the corresponding `g77'
     material.

     *Note Installing `f77': Installing f77, for more information.

Step 10: `touch f2c-install-ok'
     Don't do this if you don't want to overwrite an existing
     installation of `libf2c' (though, chances are, you do).  Instead,
     `touch f2c-exists-ok' to allow the installation to continue
     without any error messages about `/usr/lib/libf2c.a' already
     existing.

     *Note Installing `f2c': Installing f2c, for more information.

Step 11: `./configure --prefix=/usr'
     This is where you specify that the `g77' executable is to be
     installed in `/usr/bin/', the `libf2c.a' library is to be
     installed in `/usr/lib/', and so on.

     You should ensure that any existing installation of the `gcc'
     executable is in `/usr/bin/'.  Otherwise, installing `g77' so that
     it does not fully replace the existing installation of `gcc' is
     likely to result in the inability to compile Fortran programs.

     *Note Where in the World Does Fortran (and GNU CC) Go?: Where to
     Install, for more information on determining where to install
     `g77'.  *Note Configuring gcc::, for more information on the
     configuration process triggered by invoking the `./configure'
     script.

Step 12: `make bootstrap'
     *Note Installing GNU CC: (gcc)Installation, for information on the
     kinds of diagnostics you should expect during this procedure.

     *Note Building gcc::, for complete `g77'-specific information on
     this step.

Step 13: `rm -fr stage1'
     You don't need to do this, but it frees up disk space.

Step 14: `make -k install'
     If this doesn't seem to work, try:

          make -k install install-libf77 install-f2c-all

     *Note Installation of Binaries::, for more information.

     *Note Updating Your Info Directory: Updating Documentation, for
     information on entering this manual into your system's list of
     texinfo manuals.

Step 15: `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 `g77' you just built and
     installed) and the version numbers for the three parts of the
     `libf2c' library (`libF77', `libI77', `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:

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

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

          sh# g77 -o smtest smtest.f
          sh# ./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#

     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.

Complete Installation
=====================

   Here is the complete `g77'-specific information on how to configure,
build, and install `g77'.

Unpacking
---------

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

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

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

   A sequence of commands typically used to unpack `gcc' and `g77' is:

     sh# cd /usr/src
     sh# gunzip -d < /usr/FSF/gcc-2.7.2.2.tar.gz | tar xf -
     sh# gunzip -d < /usr/FSF/g77-0.5.21.tar.gz | tar xf -
     sh# ln -s gcc-2.7.2.2 gcc
     sh# ln -s g77-0.5.21 g77
     sh# mv -i g77/* gcc

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

   There are three top-level names in a `g77' distribution:

     g77/COPYING.g77
     g77/README.g77
     g77/f

   All three entries should be moved (or copied) into a `gcc' source
tree (typically named after its version number and as it appears in the
FSF distributions--e.g. `gcc-2.7.2.2').

   `g77/f' is the subdirectory containing all of the code,
documentation, and other information that is specific to `g77'.  The
other two files exist to provide information on `g77' to someone
encountering a `gcc' source tree with `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 `g77' source tree for the first time.

   *Note:* Please use *only* `gcc' and `g77' source trees as
distributed by the FSF.  Use of modified versions, such as the
Pentium-specific-optimization port of `gcc', is likely to result in
problems that appear to be in the `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 `g77' (or `gcc') source trees
appropriately so `g77' and `gcc' can coexist as they do in the stock
FSF distributions.

Merging Distributions
---------------------

   After merging the `g77' source tree into the `gcc' source tree, the
final merge step is done by applying the pertinent patches the `g77'
distribution provides for the `gcc' source tree.

   Read the file `gcc/f/gbe/README', and apply the appropriate patch
file for the version of the GNU CC compiler you have, if that exists.
If the directory exists but the appropriate file does not exist, you
are using either an old, unsupported version, or a release one that is
newer than the newest `gcc' version supported by the version of `g77'
you have.

   As of version 0.5.18, `g77' modifies the version number of `gcc' via
the pertinent patches.  This is done because the resulting version of
`gcc' is deemed sufficiently different from the vanilla distribution to
make it worthwhile to present, to the user, information signaling the
fact that there are some differences.

   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, MAJOR.MINOR.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 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 `.0' fields often are omitted in
announcements and in names for distributions and the directories they
create.)

   If your version of `gcc' is older than the oldest version supported
by `g77' (as casually determined by listing the contents of
`gcc/f/gbe/'), you should obtain a newer, supported version of `gcc'.
(You could instead obtain an older version of `g77', or try and get
your `g77' to work with the old `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 `gcc' is newer than the newest version supported
by `g77', it is possible that your `g77' will work with it anyway.  If
the version number for `gcc' differs only in the PATCH field, you might
as well try applying the `g77' patch that is for the newest version of
`gcc' having the same MAJOR and MINOR fields, as this is likely to work.

   So, for example, if a particular version of `g77' has support for
`gcc' versions 2.7.0 and 2.7.1, it is likely that `gcc-2.7.2' would
work well with `g77' by using the `2.7.1.diff' patch file provided with
`g77' (aside from some offsets reported by `patch', which usually are
harmless).

   However, `gcc-2.8.0' would almost certainly not work with that
version of `g77' no matter which patch file was used, so a new version
of `g77' would be needed (and you should wait for it rather than
bothering the maintainers--*note User-Visible Changes: Changes.).

   This complexity is the result of `gcc' and `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, `g77' often requires changes to contemporary versions of
`gcc'.  Also, the GBE interface defined by `gcc' typically undergoes
some incompatible changes at least every time the MINOR field of the
version number is incremented, and such changes require corresponding
changes to the `g77' front end (FFE).

   It is hoped that the GBE interface, and the `gcc' and `g77' products
in general, will stabilize sufficiently for the need for hand-patching
to disappear.

   Invoking `patch' as described in `gcc/f/gbe/README' can produce a
wide variety of printed output, from `Hmm, I can't seem to find a patch
in there anywhere...'  to long lists of messages indicated that patches
are being found, applied successfully, and so on.

   If messages about "fuzz", "offset", or especially "reject files" are
printed, it might mean you applied the wrong patch file.  If you
believe this is the case, it is best to restart the sequence after
deleting (or at least renaming to unused names) the top-level
directories for `g77' and `gcc' and their symbolic links.  That is
because `patch' might have partially patched some `gcc' source files,
so reapplying the correct patch file might result in the correct
patches being applied incorrectly (due to the way `patch' necessarily
works).

   After `patch' finishes, the `gcc' directory might have old versions
of several files as saved by `patch'.  To remove these, after `cd gcc',
type `rm -i *.~*~'.

   *Note:* `g77''s configuration file `gcc/f/config-lang.in' ensures
that the source code for the version of `gcc' being configured has at
least one indication of being patched as required specifically by `g77'.
This configuration-time checking should catch failure to apply the
correct patch and, if so caught, should abort the configuration with an
explanation.  *Please* do not try to disable the check, otherwise `g77'
might well appear to build and install correctly, and even appear to
compile correctly, but could easily produce broken code.

   `diff -rcp2N' is used to create the patch files in `gcc/f/gbe/'.

Installing `f77'
----------------

   You should decide whether you want installation of `g77' to also
install an `f77' command.  On systems with a native `f77', this is not
normally desired, so `g77' does not do this by default.

   If you want `f77' installed, create the file `f77-install-ok' (e.g.
via the UNIX command `touch f77-install-ok') in the source or build
top-level directory (the same directory in which the `g77' `f'
directory resides, not the `f' directory itself), or edit
`gcc/f/Make-lang.in' and change the definition of the
`F77_INSTALL_FLAG' macro appropriately.

   Usually, this means that, after typing `cd gcc', you would type
`touch f77-install-ok'.

   When you enable installation of `f77', either a link to or a direct
copy of the `g77' command is made.  Similarly, `f77.1' is installed as
a man page.

   (The `uninstall' target in the `gcc/Makefile' also tests this macro
and file, when invoked, to determine whether to delete the installed
copies of `f77' and `f77.1'.)

   *Note:* No attempt is yet made to install a program (like a shell
script) that provides compatibility with any other `f77' programs.
Only the most rudimentary invocations of `f77' will work the same way
with `g77'.

Installing `f2c'
----------------

   Currently, `g77' does not include `f2c' itself in its distribution.
However, it does include a modified version of the `libf2c'.  This
version is normally compatible with `f2c', but has been modified to
meet the needs of `g77' in ways that might possibly be incompatible
with some versions or configurations of `f2c'.

   Decide how installation of `g77' should affect any existing
installation of `f2c' on your system.

   If you do not have `f2c' on your system (e.g. no `/usr/bin/f2c', no
`/usr/include/f2c.h', and no `/usr/lib/libf2c.a', `/usr/lib/libF77.a',
or `/usr/lib/libI77.a'), you don't need to be concerned with this item.

   If you do have `f2c' on your system, you need to decide how users of
`f2c' will be affected by your installing `g77'.  Since `g77' is
currently designed to be object-code-compatible with `f2c' (with very
few, clear exceptions), users of `f2c' might want to combine
`f2c'-compiled object files with `g77'-compiled object files in a
single executable.

   To do this, users of `f2c' should use the same copies of `f2c.h' and
`libf2c.a' that `g77' uses (and that get built as part of `g77').

   If you do nothing here, the `g77' installation process will not
overwrite the `include/f2c.h' and `lib/libf2c.a' files with its own
versions, and in fact will not even install `libf2c.a' for use with the
newly installed versions of `gcc' and `g77' if it sees that
`lib/libf2c.a' exists--instead, it will print an explanatory message
and skip this part of the installation.

   To install `g77''s versions of `f2c.h' and `libf2c.a' in the
appropriate places, create the file `f2c-install-ok' (e.g. via the UNIX
command `touch f2c-install-ok') in the source or build top-level
directory (the same directory in which the `g77' `f' directory resides,
not the `f' directory itself), or edit `gcc/f/Make-lang.in' and change
the definition of the `F2C_INSTALL_FLAG' macro appropriately.

   Usually, this means that, after typing `cd gcc', you would type
`touch f2c-install-ok'.

   Make sure that when you enable the overwriting of `f2c.h' and
`libf2c.a' as used by `f2c', you have a recent and properly configured
version of `bin/f2c' so that it generates code that is compatible with
`g77'.

   If you don't want installation of `g77' to overwrite `f2c''s existing
installation, but you do want `g77' installation to proceed with
installation of its own versions of `f2c.h' and `libf2c.a' in places
where `g77' will pick them up (even when linking `f2c'-compiled object
files--which might lead to incompatibilities), create the file
`f2c-exists-ok' (e.g. via the UNIX command `touch f2c-exists-ok') in
the source or build top-level directory, or edit `gcc/f/Make-lang.in'
and change the definition of the `F2CLIBOK' macro appropriately.

Patching GNU Fortran
--------------------

   If you're using a SunOS4 system, you'll need to make the following
change to `gcc/f/proj.h': edit the line reading

     #define FFEPROJ_STRTOUL 1  ...

by replacing the `1' with `0'.  Or, you can avoid editing the source by
adding
     CFLAGS='-DFFEPROJ_STRTOUL=0 -g -O'
   to the command line for `make' when you invoke it.  (`-g' is the
default for `CFLAGS'.)

   This causes a minimal version of `strtoul()' provided as part of the
`g77' distribution to be compiled and linked into whatever `g77'
programs need it, since some systems (like SunOS4 with only the bundled
compiler and its runtime) do not provide this function in their system
libraries.

   Similarly, a minimal version of `bsearch()' is available and can be
enabled by editing a line similar to the one for `strtoul()' above in
`gcc/f/proj.h', if your system libraries lack `bsearch()'.  The method
of overriding `X_CFLAGS' may also be used.

   These are not problems with `g77', which requires an ANSI C
environment.  You should upgrade your system to one that provides a
full ANSI C environment, or encourage the maintainers of `gcc' to
provide one to all `gcc'-based compilers in future `gcc' distributions.

   *Note Problems Installing::, for more information on why `strtoul()'
comes up missing and on approaches to dealing with this problem that
have already been tried.

Where in the World Does Fortran (and GNU CC) Go?
------------------------------------------------

   Before configuring, you should make sure you know where you want the
`g77' and `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 `g77' installation necessarily requires installation of a
`g77'-aware version of `gcc', so that the `gcc' command recognizes
Fortran source files and knows how to compile them.

   For this to work, the version of `gcc' that you will be building as
part of `g77' *must* be installed as the "active" version of `gcc' on
the system.

   Sometimes people make the mistake of installing `gcc' as
`/usr/local/bin/gcc', leaving an older, non-Fortran-aware version in
`/usr/bin/gcc'.  (Or, the opposite happens.)  This can result in `g77'
being unable to compile Fortran source files, because when it calls on
`gcc' to do the actual compilation, `gcc' complains that it does not
recognize the language, or the file name suffix.

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

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

   Existing `gcc' installations typically are found in `/usr' or
`/usr/local'.  If you aren't certain where the currently installed
version of `gcc' and its related programs reside, look at the output of
this command:

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

   All sorts of interesting information on the locations of various
`gcc'-related programs and data files should be visible in the output
of the above command.  (The output also is likely to include a
diagnostic from the linker, since there's no `main_()' function.)
However, you do have to sift through it yourself; `gcc' currently
provides no easy way to ask it where it is installed and where it looks
for the various programs and data files it calls on to do its work.

   Just *building* `g77' should not overwrite any installed
programs--but, usually, after you build `g77', you will want to install
it, so backing up anything it might overwrite is a good idea.  (This is
true for any package, not just `g77', though in this case it is
intentional that `g77' overwrites `gcc' if it is already installed--it
is unusual that the installation process for one distribution
intentionally overwrites a program or file installed by another
distribution.)

   Another reason to back up the existing version first, or make sure
you can restore it easily, is that it might be an older version on
which other users have come to depend for certain behaviors.  However,
even the new version of `gcc' you install will offer users the ability
to specify an older version of the actual compilation programs if
desired, and these older versions need not include any `g77' components.
*Note Specifying Target Machine and Compiler Version: (gcc)Target
Options, for information on the `-V' option of `gcc'.

Configuring GNU CC
------------------

   `g77' is configured automatically when you configure `gcc'.  There
are two parts of `g77' that are configured in two different
ways--`g77', which "camps on" to the `gcc' configuration mechanism, and
`libf2c', which uses a variation of the GNU `autoconf' configuration
system.

   Generally, you shouldn't have to be concerned with either `g77' or
`libf2c' configuration, unless you're configuring `g77' as a
cross-compiler.  In this case, the `libf2c' configuration, and possibly
the `g77' and `gcc' configurations as well, might need special
attention.  (This also might be the case if you're porting `gcc' to a
whole new system--even if it is just a new operating system on an
existing, supported CPU.)

   To configure the system, see *Note Installing GNU CC:
(gcc)Installation, following the instructions for running `./configure'.
Pay special attention to the `--prefix=' option, which you almost
certainly will need to specify.

   (Note that `gcc' installation information is provided as a straight
text file in `gcc/INSTALL'.)

   The information printed by the invocation of `./configure' should
show that the `f' directory (the Fortran language) has been configured.
If it does not, there is a problem.

   *Note:* Configuring with the `--srcdir' argument is known to work
with GNU `make', but it is not known to work with other variants of
`make'.  Irix5.2 and SunOS4.1 versions of `make' definitely won't work
outside the source directory at present.  `g77''s portion of the
`configure' script issues a warning message about this when you
configure for building binaries outside the source directory.

Building GNU CC
---------------

   Building `g77' requires building enough of `gcc' that these
instructions assume you're going to build all of `gcc', including
`g++', `protoize', and so on.  You can save a little time and disk
space by changes the `LANGUAGES' macro definition in `gcc/Makefile.in'
or `gcc/Makefile', but if you do that, you're on your own.  One change
is almost *certainly* going to cause failures: removing `c' or `f77'
from the definition of the `LANGUAGES' macro.

   After configuring `gcc', which configures `g77' and `libf2c'
automatically, you're ready to start the actual build by invoking
`make'.

   *Note:* You *must* have run `./configure' before you run `make',
even if you're using an already existing `gcc' development directory,
because `./configure' does the work to recognize that you've added
`g77' to the configuration.

   There are two general approaches to building GNU CC from scratch:

"bootstrap"
     This method uses minimal native system facilities to build a
     barebones, unoptimized `gcc', that is then used to compile
     ("bootstrap") the entire system.

"straight"
     This method assumes a more complete native system exists, and uses
     that just once to build the entire system.

   On all systems without a recent version of `gcc' already installed,
the bootstrap method must be used.  In particular, `g77' uses
extensions to the C language offered, apparently, only by `gcc'.

   On most systems with a recent version of `gcc' already installed,
the straight method can be used.  This is an advantage, because it
takes less CPU time and disk space for the build.  However, it does
require that the system have fairly recent versions of many GNU
programs and other programs, which are not enumerated here.

Bootstrap Build
...............

   A complete bootstrap build is done by issuing a command beginning
with `make bootstrap ...', as described in *Note Installing GNU CC:
(gcc)Installation.  This is the most reliable form of build, but it
does require the most disk space and CPU time, since the complete system
is built twice (in Stages 2 and 3), after an initial build (during
Stage 1) of a minimal `gcc' compiler using the native compiler and
libraries.

   You might have to, or want to, control the way a bootstrap build is
done by entering the `make' commands to build each stage one at a time,
as described in the `gcc' manual.  For example, to save time or disk
space, you might want to not bother doing the Stage 3 build, in which
case you are assuming that the `gcc' compiler you have built is
basically sound (because you are giving up the opportunity to compare a
large number of object files to ensure they're identical).

   To save some disk space during installation, after Stage 2 is built,
you can type `rm -fr stage1' to remove the binaries built during Stage
1.

   *Note:* *Note Object File Differences::, for information on expected
differences in object files produced during Stage 2 and Stage 3 of a
bootstrap build.  These differences will be encountered as a result of
using the `make compare' or similar command sequence recommended by the
GNU CC installation documentation.

   Also, *Note Installing GNU CC: (gcc)Installation, for important
information on building `gcc' that is not described in this `g77'
manual.  For example, explanations of diagnostic messages and whether
they're expected, or indicate trouble, are found there.

Straight Build
..............

   If you have a recent version of `gcc' already installed on your
system, and if you're reasonably certain it produces code that is
object-compatible with the version of `gcc' you want to build as part
of building `g77', you can save time and disk space by doing a straight
build.

   To build just the C and Fortran compilers and the necessary run-time
libraries, issue the following command:

     make -k CC=gcc LANGUAGES=f77 all g77

   (The `g77' target is necessary because the `gcc' build procedures
apparently do not automatically build command drivers for languages in
subdirectories.  It's the `all' target that triggers building
everything except, apparently, the `g77' command itself.)

   If you run into problems using this method, you have two options:

   * Abandon this approach and do a bootstrap build.

   * Try to make this approach work by diagnosing the problems you're
     running into and retrying.

   Especially if you do the latter, you might consider submitting any
solutions as bug/fix reports.  *Note Known Causes of Trouble with GNU
Fortran: Trouble.

   However, understand that many problems preventing a straight build
from working are not `g77' problems, and, in such cases, are not likely
to be addressed in future versions of `g77'.

Pre-installation Checks
-----------------------

   Before installing the system, which includes installing `gcc', you
might want to do some minimum checking to ensure that some basic things
work.

   Here are some commands you can try, and output typically printed by
them when they work:

     sh# cd /usr/src/gcc
     sh# ./g77 --driver=./xgcc -B./ -v
     g77 version 0.5.21
      ./xgcc -B./ -v -fnull-version -o /tmp/gfa18047 ...
     Reading specs from ./specs
     gcc version 2.7.2.2.f.3
      ./cpp -lang-c -v -isystem ./include -undef ...
     GNU CPP version 2.7.2.2.f.3 (Linux/Alpha)
     #include "..." search starts here:
     #include <...> search starts here:
      ./include
      /usr/local/include
      /usr/alpha-unknown-linux/include
      /usr/lib/gcc-lib/alpha-unknown-linux/2.7.2.2.f.3/include
      /usr/include
     End of search list.
      ./f771 /tmp/cca18048.i -fset-g77-defaults -quiet -dumpbase ...
     GNU F77 version 2.7.2.2.f.3 (Linux/Alpha) compiled ...
     GNU Fortran Front End version 0.5.21 compiled: ...
      as -nocpp -o /tmp/cca180481.o /tmp/cca18048.s
      ld -G 8 -O1 -o /tmp/gfa18047 /usr/lib/crt0.o -L. ...
     __G77_LIBF77_VERSION__: 0.5.21
     @(#)LIBF77 VERSION 19970404
     __G77_LIBI77_VERSION__: 0.5.21
     @(#) LIBI77 VERSION pjw,dmg-mods 19970527
     __G77_LIBU77_VERSION__: 0.5.21
     @(#) LIBU77 VERSION 19970609
     sh# ./xgcc -B./ -v -o /tmp/delete-me -xc /dev/null -xnone
     Reading specs from ./specs
     gcc version 2.7.2.2.f.3
      ./cpp -lang-c -v -isystem ./include -undef ...
     GNU CPP version 2.7.2.2.f.3 (Linux/Alpha)
     #include "..." search starts here:
     #include <...> search starts here:
      ./include
      /usr/local/include
      /usr/alpha-unknown-linux/include
      /usr/lib/gcc-lib/alpha-unknown-linux/2.7.2.2.f.3/include
      /usr/include
     End of search list.
      ./cc1 /tmp/cca18063.i -quiet -dumpbase null.c -version ...
     GNU C version 2.7.2.2.f.3 (Linux/Alpha) compiled ...
      as -nocpp -o /tmp/cca180631.o /tmp/cca18063.s
      ld -G 8 -O1 -o /tmp/delete-me /usr/lib/crt0.o -L. ...
     /usr/lib/crt0.o: In function `__start':
     crt0.S:110: undefined reference to `main'
     /usr/lib/crt0.o(.lita+0x28): undefined reference to `main'
     sh#

   (Note that long lines have been truncated, and `...'  used to
indicate such truncations.)

   The above two commands test whether `g77' and `gcc', respectively,
are able to compile empty (null) source files, whether invocation of
the C preprocessor works, whether libraries can be linked, and so on.

   If the output you get from either of the above two commands is
noticeably different, especially if it is shorter or longer in ways
that do not look consistent with the above sample output, you probably
should not install `gcc' and `g77' until you have investigated further.

   For example, you could try compiling actual applications and seeing
how that works.  (You might want to do that anyway, even if the above
tests work.)

   To compile using the not-yet-installed versions of `gcc' and `g77',
use the following commands to invoke them.

   To invoke `g77', type:

     /usr/src/gcc/g77 --driver=/usr/src/gcc/xgcc -B/usr/src/gcc/ ...

   To invoke `gcc', type:

     /usr/src/gcc/xgcc -B/usr/src/gcc/ ...

Installation of Binaries
------------------------

   After configuring, building, and testing `g77' and `gcc', when you
are ready to install them on your system, type:

     make -k CC=gcc LANGUAGES=f77 install

   As described in *Note Installing GNU CC: (gcc)Installation, the
values for the `CC' and `LANGUAGES' macros should be the same as those
you supplied for the build itself.

   So, the details of the above command might vary if you used a
bootstrap build (where you might be able to omit both definitions, or
might have to supply the same definitions you used when building the
final stage) or if you deviated from the instructions for a straight
build.

   If the above command does not install `libf2c.a' as expected, try
this:

     make -k ... install install-libf77 install-f2c-all

   We don't know why some non-GNU versions of `make' sometimes require
this alternate command, but they do.  (Remember to supply the
appropriate definitions for `CC' and `LANGUAGES' where you see `...' in
the above command.)

   Note that using the `-k' option tells `make' to continue after some
installation problems, like not having `makeinfo' installed on your
system.  It might not be necessary for your system.

Updating Your Info Directory
----------------------------

   As part of installing `g77', you should make sure users of `info'
can easily access this manual on-line.  Do this by making sure a line
such as the following exists in `/usr/info/dir', or in whatever file is
the top-level file in the `info' directory on your system (perhaps
`/usr/local/info/dir':

     * g77: (g77).           The GNU Fortran programming language.

   If the menu in `dir' is organized into sections, `g77' probably
belongs in a section with a name such as one of the following:

   * Fortran Programming

   * Writing Programs

   * Programming Languages

   * Languages Other Than C

   * Scientific/Engineering Tools

   * GNU Compilers

Missing `bison'?
----------------

   If you cannot install `bison', make sure you have started with a
*fresh* distribution of `gcc', do *not* do `make maintainer-clean' (in
other versions of `gcc', this was called `make realclean'), and, to
ensure that `bison' is not invoked by `make' during the build, type
these commands:

     sh# cd gcc
     sh# touch bi-parser.c bi-parser.h c-parse.c c-parse.h cexp.c
     sh# touch cp/parse.c cp/parse.h objc-parse.c
     sh#

   These commands update the date-time-modified information for all the
files produced by the various invocations of `bison' in the current
versions of `gcc', so that `make' no longer believes it needs to update
them.  All of these files should already exist in a `gcc' distribution,
but the application of patches to upgrade to a newer version can leave
the modification information set such that the `bison' input files look
more "recent" than the corresponding output files.

   *Note:* New versions of `gcc' might change the set of files it
generates by invoking `bison'--if you cannot figure out for yourself
how to handle such a situation, try an older version of `gcc' until you
find someone who can (or until you obtain and install `bison').

Missing `makeinfo'?
-------------------

   If you cannot install `makeinfo', either use the `-k' option when
invoking make to specify any of the `install' or related targets, or
specify `MAKEINFO=echo' on the `make' command line.

   If you fail to do one of these things, some files, like `libf2c.a',
might not be installed, because the failed attempt by `make' to invoke
`makeinfo' causes it to cancel any further processing.

Distributing Binaries
=====================

   If you are building `g77' for distribution to others in binary form,
first make sure you are aware of your legal responsibilities (read the
file `gcc/COPYING' thoroughly).

   Then, consider your target audience and decide where `g77' should be
installed.

   For systems like GNU/Linux that have no native Fortran compiler (or
where `g77' could be considered the native compiler for Fortran and
`gcc' for C, etc.), you should definitely configure `g77' for
installation in `/usr/bin' instead of `/usr/local/bin'.  Specify the
`--prefix=/usr' option when running `./configure'.  You might also want
to set up the distribution so the `f77' command is a link to
`g77'--just make an empty file named `f77-install-ok' in the source or
build directory (the one in which the `f' directory resides, not the
`f' directory itself) when you specify one of the `install' or
`uninstall' targets in a `make' command.

   For a system that might already have `f2c' installed, you definitely
will want to make another empty file (in the same directory) named
either `f2c-exists-ok' or `f2c-install-ok'.  Use the former if you
don't want your distribution to overwrite `f2c'-related files in
existing systems; use the latter if you want to improve the likelihood
that users will be able to use both `f2c' and `g77' to compile code for
a single program without encountering link-time or run-time
incompatibilities.

   (Make sure you clearly document, in the "advertising" for your
distribution, how installation of your distribution will affect
existing installations of `gcc', `f2c', `f77', `libf2c.a', and so on.
Similarly, you should clearly document any requirements you assume are
met by users of your distribution.)

   For other systems with native `f77' (and `cc') compilers, configure
`g77' as you (or most of your audience) would configure `gcc' for their
installations.  Typically this is for installation in `/usr/local', and
would not include a copy of `g77' named `f77', so users could still use
the native `f77'.

   In any case, for `g77' to work properly, you *must* ensure that the
binaries you distribute include:

`bin/g77'
     This is the command most users use to compile Fortran.

`bin/gcc'
     This is the command all users use to compile Fortran, either
     directly or indirectly via the `g77' command.  The `bin/gcc'
     executable file must have been built from a `gcc' source tree into
     which a `g77' source tree was merged and configured, or it will
     not know how to compile Fortran programs.

`bin/f77'
     In installations with no non-GNU native Fortran compiler, this is
     the same as `bin/g77'.  Otherwise, it should be omitted from the
     distribution, so the one on already on a particular system does
     not get overwritten.

`info/g77.info*'
     This is the documentation for `g77'.  If it is not included, users
     will have trouble understanding diagnostics messages and other
     such things, and will send you a lot of email asking questions.

     Please edit this documentation (by editing `gcc/f/*.texi' and
     doing `make doc' from the `/usr/src/gcc' directory) to reflect any
     changes you've made to `g77', or at least to encourage users of
     your binary distribution to report bugs to you first.

     Also, whether you distribute binaries or install `g77' on your own
     system, it might be helpful for everyone to add a line listing
     this manual by name and topic to the top-level `info' node in
     `/usr/info/dir'.  That way, users can find `g77' documentation more
     easily.  *Note Updating Your Info Directory: Updating
     Documentation.

`man/man1/g77.1'
     This is the short man page for `g77'.  It is out of date, but you
     might as well include it for people who really like man pages.

`man/man1/f77.1'
     In installations where `f77' is the same as `g77', this is the
     same as `man/man1/g77.1'.  Otherwise, it should be omitted from
     the distribution, so the one already on a particular system does
     not get overwritten.

`lib/gcc-lib/.../f771'
     This is the actual Fortran compiler.

`lib/gcc-lib/.../libf2c.a'
     This is the run-time library for `g77'-compiled programs.

   Whether you want to include the slightly updated (and possibly
improved) versions of `cc1', `cc1plus', and whatever other binaries get
rebuilt with the changes the GNU Fortran distribution makes to the GNU
back end, is up to you.  These changes are highly unlikely to break any
compilers, and it is possible they'll fix back-end bugs that can be
demonstrated using front ends other than GNU Fortran's.

   Please assure users that unless they have a specific need for their
existing, older versions of `gcc' command, they are unlikely to
experience any problems by overwriting it with your version--though
they could certainly protect themselves by making backup copies first!
Otherwise, users might try and install your binaries in a "safe" place,
find they cannot compile Fortran programs with your distribution
(because, perhaps, they're picking up their old version of the `gcc'
command, which does not recognize Fortran programs), and assume that
your binaries (or, more generally, GNU Fortran distributions in
general) are broken, at least for their system.

   Finally, *please* ask for bug reports to go to you first, at least
until you're sure your distribution is widely used and has been well
tested.  This especially goes for those of you making any changes to
the `g77' sources to port `g77', e.g. to OS/2.
<fortran@gnu.ai.mit.edu> has received a fair number of bug reports that
turned out to be problems with other peoples' ports and distributions,
about which nothing could be done for the user.  Once you are quite
certain a bug report does not involve your efforts, you can forward it
to us.