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.
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
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 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 from the FSF,
the same way you obtained gcc.
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
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
make, and you will probably save
yourself a lot of trouble if it is GNU make (sometimes
referred to as gmake).
cc
gcc.
bison
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.
See section Missing bison?,
for information on how to work around not having bison.
makeinfo
makeinfo, you can usually work
around any need for it.
You can obtain makeinfo the same way you obtained
gcc and g77.
See section Missing makeinfo?,
for information on getting around the lack of makeinfo.
root access
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.
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.
See section `Installation Problems' in Using and Porting GNU CC,
for more information on installation problems that can afflict
either gcc or g77.
These problems can occur on most or all systems.
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.
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).
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.
On SunOS4 systems, linking the f771 program produces
an error message concerning an undefined symbol named
`_strtoul'.
This is not a g77 bug.
See section 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.
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.
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.
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.
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.
libf2c is built could make
building g77 as a cross-compiler easier--for example,
passing and using `LD' and `AR' in the appropriate
ways.
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.)
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.
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.
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.
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. See section Bugs Not In GNU Fortran, for more information.
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/'.)
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.
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.
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.20.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:
Instead, see section Complete Installation, for detailed information
on how to configure, build, and install g77 for your
particular system.
Also, see section Known Causes of Trouble with GNU Fortran,
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.20.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.20 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]#
See section Updating Your Info Directory, 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:
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.
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.20 of g77.
g77.
See section Unpacking, for information on
using distributions of g77 made by organizations
other than the FSF.
g77 are
installed on your system.
See section Unpacking, for information
on the contents of the `g77' directory (as merged
into the `gcc' directory).
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 *.~*~.
See section Merging Distributions, for more information.
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.
See section Installing f77, for more
information.
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.
See section Installing f2c, for more
information.
g77 so that it does not fully
replace the existing installation of gcc is likely
to result in the inability to compile Fortran programs.
See section Where in the World Does Fortran (and GNU CC) Go?,
for more information on determining where to install g77.
See section Configuring GNU CC, for more information on the
configuration process triggered by invoking the `./configure'
script.
g77-specific
information on this step.
make -k install install-libf77 install-f2c-allSee section Installation of Binaries, for more information. See section Updating Your Info Directory, for information on entering this manual into your system's list of texinfo manuals.
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.
Here is the complete g77-specific information on how
to configure, build, and install g77.
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.20.tar.gz | tar xf - sh# ln -s gcc-2.7.2.2 gcc sh# ln -s g77-0.5.20 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.
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---see section User-visible 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/'.
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.
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.
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.
See section Problems Installing, for more information on
why strtoul() comes up missing and on approaches
to dealing with this problem that have already been tried.
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.
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.
See section `Specifying Target Machine and Compiler Version' in Using and Porting GNU CC, for information on the `-V'
option of gcc.
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 section `Installing GNU CC' in Using and Porting GNU CC, 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 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:
gcc, that is then
used to compile ("bootstrap") 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.
A complete bootstrap build is done by issuing a command
beginning with `make bootstrap ...', as
described in section `Installing GNU CC' in Using and Porting GNU CC.
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: See section 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, See section `Installing GNU CC' in Using and Porting GNU CC,
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.
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:
Especially if you do the latter, you might consider submitting any solutions as bug/fix reports. See section Known Causes of Trouble with GNU Fortran.
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.
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.20 ./xgcc -B./ -v -fnull-version -o /tmp/gfa18047 ... Reading specs from ./specs gcc version 2.7.2.2.f.2 ./cpp -lang-c -v -isystem ./include -undef ... GNU CPP version 2.7.2.2.f.2 (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.2/include /usr/include End of search list. ./f771 /tmp/cca18048.i -fset-g77-defaults -quiet -dumpbase ... GNU F77 version 2.7.2.2.f.2 (Linux/Alpha) compiled ... GNU Fortran Front End version 0.5.20-970224 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.20 @(#)LIBF77 VERSION 19960619 __G77_LIBI77_VERSION__: 0.5.20 @(#) LIBI77 VERSION pjw,dmg-mods 19961209 __G77_LIBU77_VERSION__: 0.5.20 @(#) LIBU77 VERSION 19970204 sh# ./xgcc -B./ -v -o /tmp/delete-me -xc /dev/null -xnone Reading specs from ./specs gcc version 2.7.2.2.f.2 ./cpp -lang-c -v -isystem ./include -undef ... GNU CPP version 2.7.2.2.f.2 (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.2/include /usr/include End of search list. ./cc1 /tmp/cca18063.i -quiet -dumpbase null.c -version ... GNU C version 2.7.2.2.f.2 (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/ ...
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 section `Installing GNU CC' in Using and Porting GNU CC, 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.
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:
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).
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.
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:
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.
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.
See section Updating Your Info Directory.
g77.
It is out of date, but you might as well include it
for people who really like man pages.
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.
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.
@email{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.
Go to the first, previous, next, last section, table of contents.