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/'.
Go to the first, previous, next, last section, table of contents.