The following information describes how to install g77.
Note that, for users of the GCC-2.95 version of g77, much of the information is obsolete, and is superceded by the GCC installation procedures. Such information is accordingly omitted and flagged as such.
For users of the GCC-2.95 version of g77, this information is superceded by the GCC installation instructions.
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 no longer requires application of a patch file to the gcc compiler tree. In fact, no such patch file is distributed with g77. This is as of version 0.5.23 and egcs version 1.0.
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.
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.
That help has arrived as of version 0.5.23 of g77 and version 1.1 of egcs. Configuration itself no longer creates any particular directories that are unique to g77. The build procedures in `Make-lang.in' take care of that, on demand.
Prior to version 0.5.23 of g77 and version 1.1 of egcs, g77 would sometimes ignore the absence of f77 and F77 in the LANGUAGES macro definition used for the make command being processed.
As of g77 version 0.5.23 and egcs version 1.1, g77 now obeys this macro in all relevant situations.
However, in versions of gcc through 2.8.1, non-g77 portions of gcc, such as g++, are known to go ahead and perform various language-specific activities when their respective language strings do not appear in the LANGUAGES macro in effect during that invocation of make.
It is expected that these remaining problems will be fixed in a future version of gcc.
A linker bug on some versions of AIX 4.1 might prevent building when g77 is built within gcc. It might also occur when building within egcs. See section LINKFAIL.
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.
Here are some internal g77 settings that can be changed by editing source files in `egcs/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.
g77, on most machines, puts many variables and arrays on the stack where possible, and can be configured (by changing FFECOM_sizeMAXSTACKITEM in `egcs/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.
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 `egcs/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.
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.