1606 lines
68 KiB
Plaintext
1606 lines
68 KiB
Plaintext
|
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.
|
||
|
|
|
||
|
|
Note most of this information is out of date and superceded by the EGCS
|
||
|
|
install procedures. It is provided for historical reference only.
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
The version of GNU `gzip' used to package this release is 1.24.
|
||
|
|
(The version of GNU `tar' used to package this release is 1.11.2.)
|
||
|
|
|
||
|
|
`gcc-2.7.2.3.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. Its size is approximately 7.1MB.
|
||
|
|
|
||
|
|
If you've already unpacked `gcc-2.7.2.3.tar.gz' into a directory
|
||
|
|
(named `gcc-2.7.2.3') 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 package, or you are
|
||
|
|
reading an advance copy of these installation instructions, which
|
||
|
|
are contained in this distribution. The size of this package is
|
||
|
|
approximately 1.5MB.
|
||
|
|
|
||
|
|
You can obtain an FSF distribution of `g77' from the FSF, the same
|
||
|
|
way you obtained `gcc'.
|
||
|
|
|
||
|
|
Enough disk space
|
||
|
|
The amount of disk space needed to unpack, build, install, and use
|
||
|
|
`g77' depends on the type of system you're using, how you build
|
||
|
|
`g77', and how much of it you install (primarily, which languages
|
||
|
|
you install).
|
||
|
|
|
||
|
|
The sizes shown below assume all languages distributed in
|
||
|
|
`gcc-2.7.2.3', plus `g77', will be built and installed. These
|
||
|
|
sizes are indicative of GNU/Linux systems on Intel x86 running
|
||
|
|
COFF and on Digital Alpha (AXP) systems running ELF. These should
|
||
|
|
be fairly representative of 32-bit and 64-bit systems,
|
||
|
|
respectively.
|
||
|
|
|
||
|
|
Note that all sizes are approximate and subject to change without
|
||
|
|
notice! They are based on preliminary releases of g77 made shortly
|
||
|
|
before the public beta release.
|
||
|
|
|
||
|
|
-- `gcc' and `g77' distributions occupy 8.6MB packed, 35MB
|
||
|
|
unpacked. These consist of the source code and documentation,
|
||
|
|
plus some derived files (mostly documentation), for `gcc' and
|
||
|
|
`g77'. Any deviations from these numbers for different kinds
|
||
|
|
of systems are likely to be very minor.
|
||
|
|
|
||
|
|
-- A "bootstrap" build requires an additional 67.3MB for a
|
||
|
|
total of 102MB on an ix86, and an additional 98MB for a total
|
||
|
|
of 165MB on an Alpha.
|
||
|
|
|
||
|
|
-- Removing `gcc/stage1' after the build recovers 10.7MB for a
|
||
|
|
total of 91MB on an ix86, and recovers ??MB for a total of
|
||
|
|
??MB on an Alpha.
|
||
|
|
|
||
|
|
After doing this, the integrity of the build can still be
|
||
|
|
verified via `make compare', and the `gcc' compiler modified
|
||
|
|
and used to build itself for testing fairly quickly, using
|
||
|
|
the copy of the compiler kept in `gcc/stage2'.
|
||
|
|
|
||
|
|
-- Removing `gcc/stage2' after the build further recovers
|
||
|
|
27.3MB for a total of 64.3MB, and recovers ??MB for a total
|
||
|
|
of ??MB on an Alpha.
|
||
|
|
|
||
|
|
After doing this, the compiler can still be installed,
|
||
|
|
especially if GNU `make' is used to avoid gratuitous rebuilds
|
||
|
|
(or, the installation can be done by hand).
|
||
|
|
|
||
|
|
-- Installing `gcc' and `g77' copies 14.9MB onto the `--prefix'
|
||
|
|
disk for a total of 79.2MB on an ix86, and copies ??MB onto
|
||
|
|
the `--prefix' disk for a total of ??MB on an Alpha.
|
||
|
|
|
||
|
|
After installation, if no further modifications and builds of
|
||
|
|
`gcc' or `g77' are planned, the source and build directory may be
|
||
|
|
removed, leaving the total impact on a system's disk storage as
|
||
|
|
that of the amount copied during installation.
|
||
|
|
|
||
|
|
Systems with the appropriate version of `gcc' installed don't
|
||
|
|
require the complete bootstrap build. Doing a "straight build"
|
||
|
|
requires about as much space as does a bootstrap build followed by
|
||
|
|
removing both the `gcc/stage1' and `gcc/stage2' directories.
|
||
|
|
|
||
|
|
Installing `gcc' and `g77' over existing versions might require
|
||
|
|
less *new* disk space, but note that, unlike many products, `gcc'
|
||
|
|
installs itself in a way that avoids overwriting other installed
|
||
|
|
versions of itself, so that other versions may easily be invoked
|
||
|
|
(via `gcc -V VERSION').
|
||
|
|
|
||
|
|
So, the amount of space saved as a result of having an existing
|
||
|
|
version of `gcc' and `g77' already installed is not
|
||
|
|
much--typically only the command drivers (`gcc', `g77', `g++', and
|
||
|
|
so on, which are small) and the documentation is overwritten by
|
||
|
|
the new installation. The rest of the new installation is done
|
||
|
|
without replacing existing installed versions (assuming they have
|
||
|
|
different version numbers).
|
||
|
|
|
||
|
|
`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.
|
||
|
|
|
||
|
|
The version of GNU `patch' used to develop this release is 2.4.
|
||
|
|
|
||
|
|
`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').
|
||
|
|
|
||
|
|
The version of GNU `make' used to develop this release is 3.73.
|
||
|
|
|
||
|
|
`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'.
|
||
|
|
|
||
|
|
The version of GNU `bison' used to develop this release is 1.25.
|
||
|
|
|
||
|
|
*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'.
|
||
|
|
|
||
|
|
The version of GNU `makeinfo' used to develop this release is
|
||
|
|
1.68, from GNU `texinfo' version 3.11.
|
||
|
|
|
||
|
|
*Note Missing makeinfo?::, for information on getting around the
|
||
|
|
lack of `makeinfo'.
|
||
|
|
|
||
|
|
`sed'
|
||
|
|
All UNIX systems have `sed', but some have a broken version that
|
||
|
|
cannot handle configuring, building, or installing `gcc' or `g77'.
|
||
|
|
|
||
|
|
The version of GNU `sed' used to develop this release is 2.05.
|
||
|
|
(Note that GNU `sed' version 3.0 was withdrawn by the FSF--if you
|
||
|
|
happen to have this version installed, replace it with version
|
||
|
|
2.05 immediately. See a GNU distribution site for further
|
||
|
|
explanation.)
|
||
|
|
|
||
|
|
`root' access or equivalent
|
||
|
|
To perform the complete installation procedures on a system, you
|
||
|
|
need to have `root' access to that system, or equivalent access to
|
||
|
|
the `--prefix' directory tree specified on the `configure' command
|
||
|
|
line.
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
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.3.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.3.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.3 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.3.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]# make compare
|
||
|
|
[This verifies that the compiler is `sane'. Only
|
||
|
|
the file `f/zzz.o' (aka `tmp-foo1' and `tmp-foo2')
|
||
|
|
should be in the list of object files this command
|
||
|
|
prints as having different contents. If other files
|
||
|
|
are printed, you have likely found a g77 bug.]
|
||
|
|
|
||
|
|
sh[14]# rm -fr stage1
|
||
|
|
|
||
|
|
sh[15]# make -k install
|
||
|
|
[The actual installation.]
|
||
|
|
|
||
|
|
sh[16]# g77 -v
|
||
|
|
[Verify that g77 is installed, obtain version info.]
|
||
|
|
|
||
|
|
sh[17]#
|
||
|
|
|
||
|
|
*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.3 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: `make compare'
|
||
|
|
*Note Where to Port Bugs: Bug Lists, for information on where to
|
||
|
|
report that you observed more than `f/zzz.o' having different
|
||
|
|
contents during this phase.
|
||
|
|
|
||
|
|
*Note How to Report Bugs: Bug Reporting, for information on *how*
|
||
|
|
to report bugs like this.
|
||
|
|
|
||
|
|
Step 14: `rm -fr stage1'
|
||
|
|
You don't need to do this, but it frees up disk space.
|
||
|
|
|
||
|
|
Step 15: `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 16: `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 -c /usr/FSF/gcc-2.7.2.3.tar.gz | tar xf -
|
||
|
|
sh# gunzip -c /usr/FSF/g77-0.5.21.tar.gz | tar xf -
|
||
|
|
sh# ln -s gcc-2.7.2.3 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.3').
|
||
|
|
|
||
|
|
`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.3.f.1
|
||
|
|
./cpp -lang-c -v -isystem ./include -undef ...
|
||
|
|
GNU CPP version 2.7.2.3.f.1 (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.3.f.1/include
|
||
|
|
/usr/include
|
||
|
|
End of search list.
|
||
|
|
./f771 /tmp/cca18048.i -fset-g77-defaults -quiet -dumpbase ...
|
||
|
|
GNU F77 version 2.7.2.3.f.1 (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 19970816
|
||
|
|
__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.3.f.1
|
||
|
|
./cpp -lang-c -v -isystem ./include -undef ...
|
||
|
|
GNU CPP version 2.7.2.3.f.1 (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.3.f.1/include
|
||
|
|
/usr/include
|
||
|
|
End of search list.
|
||
|
|
./cc1 /tmp/cca18063.i -quiet -dumpbase null.c -version ...
|
||
|
|
GNU C version 2.7.2.3.f.1 (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.org> 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.
|
||
|
|
|