diff options
Diffstat (limited to 'gnu/usr.bin/gcc/f/g77.info-5')
| -rw-r--r-- | gnu/usr.bin/gcc/f/g77.info-5 | 1085 |
1 files changed, 0 insertions, 1085 deletions
diff --git a/gnu/usr.bin/gcc/f/g77.info-5 b/gnu/usr.bin/gcc/f/g77.info-5 deleted file mode 100644 index de90bb41ba6..00000000000 --- a/gnu/usr.bin/gcc/f/g77.info-5 +++ /dev/null @@ -1,1085 +0,0 @@ -This is Info file g77.info, produced by Makeinfo-1.64 from the input -file g77.texi. - - This file explains how to use the GNU Fortran system. - - Published by the Free Software Foundation 59 Temple Place - Suite 330 -Boston, MA 02111-1307 USA - - Copyright (C) 1995, 1996 Free Software Foundation, Inc. - - Permission is granted to make and distribute verbatim copies of this -manual provided the copyright notice and this permission notice are -preserved on all copies. - - Permission is granted to copy and distribute modified versions of -this manual under the conditions for verbatim copying, provided also -that the sections entitled "GNU General Public License," "Funding for -Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are -included exactly as in the original, and provided that the entire -resulting derived work is distributed under the terms of a permission -notice identical to this one. - - Permission is granted to copy and distribute translations of this -manual into another language, under the above conditions for modified -versions, except that the sections entitled "GNU General Public -License," "Funding for Free Software," and "Protect Your Freedom--Fight -`Look And Feel'", and this permission notice, may be included in -translations approved by the Free Software Foundation instead of in the -original English. - - Contributed by James Craig Burley (`burley@gnu.ai.mit.edu'). -Inspired by a first pass at translating `g77-0.5.16/f/DOC' that was -contributed to Craig by David Ronis (`ronis@onsager.chem.mcgill.ca'). - - -File: g77.info, Node: Merging Distributions, Next: Installing f77, Prev: Unpacking, Up: Complete Installation - -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. - - 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 `g77' has support for 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 GBE function required specifically by `g77'. This function -was added to `gcc-2.7.1', making the patch file -`g77-0.5.17/f/gbe/2.7.1.diff' empty of actual patches. - - For `gcc-2.7.0' and earlier, this configuration-time checking should -catch failure to apply the correct patch and, if so caught, it 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/'. - - -File: g77.info, Node: Installing f77, Next: Installing f2c, Prev: Merging Distributions, Up: Complete Installation - -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'. - - -File: g77.info, Node: Installing f2c, Next: Patching GNU Fortran, Prev: Installing f77, Up: Complete Installation - -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. - - -File: g77.info, Node: Patching GNU Fortran, Next: Where to Install, Prev: Installing f2c, Up: Complete Installation - -Patching GNU Fortran --------------------- - - If you're using a SunOS 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'. - - 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 SunOS) 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()'. - - 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. - - -File: g77.info, Node: Where to Install, Next: Configuring gcc, Prev: Patching GNU Fortran, Up: Complete Installation - -Where in the World Does Fortran (and GNU C) 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. 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'. - - -File: g77.info, Node: Configuring gcc, Next: Building gcc, Prev: Where to Install, Up: Complete Installation - -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. - - -File: g77.info, Node: Building gcc, Next: Pre-installation Checks, Prev: Configuring gcc, Up: Complete Installation - -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. - -* Menu: - -* Bootstrap Build:: For all systems. -* Straight Build:: For systems with a recent version of `gcc'. - - -File: g77.info, Node: Bootstrap Build, Next: Straight Build, Up: Building gcc - -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:* If you do build Stage 3 and you compare the object files -produced by various stages, the file `gcc/f/zzz.o' *will* be different. -That is because it contains a string with an expansion of the -`__TIME__' macro, which expands to the current time of day. It is -nothing to worry about, since `gcc/f/zzz.c' doesn't contain any actual -code. It does allow you to override its use of `__DATE__' and -`__TIME__' by defining macros for the compilation--see the source code -for details. - - *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. - - -File: g77.info, Node: Straight Build, Prev: Bootstrap Build, Up: Building gcc - -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'. - - -File: g77.info, Node: Pre-installation Checks, Next: Installation of Binaries, Prev: Building gcc, Up: Complete Installation - -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' - ./xgcc -B./ -v -fnull-version -o /tmp/gfa03648 ... - Reading specs from ./specs - gcc version 2.7.1 - ./cpp -lang-c -v -isystem ./include -undef ... - GNU CPP version 2.7.1 (80386, BSD syntax) - #include "..." search starts here: - #include <...> search starts here: - ./include - /usr/include - /usr/i486-unknown-linuxaout/include - /usr/lib/gcc-lib/i486-unknown-linuxaout/2.7.1/include - /usr/include - End of search list. - ./f771 /tmp/cca03648.i -quiet -dumpbase null.F -version ... - GNU F77 version 2.7.1 (80386, BSD syntax) compiled ... - GNU Fortran Front End version 0.5.18 compiled: ... - as -o /tmp/cca036481.o /tmp/cca03648.s - ld -m i386linux -o /tmp/gfa03648 /usr/lib/crt0.o -L. ... - /usr/lib/crt0.o(.text+0x35): undefined reference to `main' - sh# `./xgcc -B./ -v -o /tmp/delete-me -xc /dev/null -xnone' - Reading specs from ./specs - gcc version 2.7.1 - ./cpp -lang-c -v -isystem ./include -undef ... - GNU CPP version 2.7.1 (80386, BSD syntax) - #include "..." search starts here: - #include <...> search starts here: - ./include - /usr/include - /usr/i486-unknown-linuxaout/include - /usr/lib/gcc-lib/i486-unknown-linuxaout/2.7.1/include - /usr/include - End of search list. - ./cc1 /tmp/cca03659.i -quiet -dumpbase null.c -version ... - GNU C version 2.7.1 (80386, BSD syntax) compiled ... - as -o /tmp/cca036591.o /tmp/cca03659.s - ld -m i386linux -o /tmp/delete-me /usr/lib/crt0.o -L. ... - /usr/lib/crt0.o(.text+0x35): 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 (even though -there is an undefined reference due to there being no main program -unit), and so on. - - If the output you get from either of the above two commands is -noticably 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/ ... - - -File: g77.info, Node: Installation of Binaries, Next: Updating Documentation, Prev: Pre-installation Checks, Up: Complete Installation - -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. - - -File: g77.info, Node: Updating Documentation, Next: Missing bison?, Prev: Installation of Binaries, Up: Complete Installation - -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 the following: - - * Writing Programs - - * Programming Languages - - * Languages Other Than C - - * Scientific/Engineering Tools - - * GNU Compilers - - -File: g77.info, Node: Missing bison?, Next: Missing makeinfo?, Prev: Updating Documentation, Up: Complete Installation - -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'). - - -File: g77.info, Node: Missing makeinfo?, Prev: Missing bison?, Up: Complete Installation - -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. - - -File: g77.info, Node: Distributing Binaries, Next: Settings, Prev: Complete Installation, Up: Installation - -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 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'. - - 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'. - -`man/man1/f77.1' - In installations where `f77' is the same as `g77', this is the - same as `man/man1/g77.1'. Otherwise, it should be omitted from - the distribution, so the one already on a particular system does - not get overwritten. - -`lib/gcc-lib/.../f771' - This is the actual Fortran compiler. - -`lib/gcc-lib/.../libf2c.a' - This is the run-time library for `g77'-compiled programs. - - Whether you want to include the slightly updated (and possibly -improved) versions of `cc1', `cc1plus', and whatever other binaries get -rebuilt with the changes the GNU Fortran distribution makes to the GNU -back end, is up to you. These changes are highly unlikely to break any -compilers, and it is possible they'll fix back-end bugs that can be -demonstrated using front ends other than GNU Fortran's. - - Please assure users that unless they have a specific need for their -existing, older versions of `gcc' command, they are unlikely to -experience any problems by overwriting it with your version--though -they could certainly protect themselves by making backup copies first! -Otherwise, users might try and install your binaries in a "safe" place, -find they cannot compile Fortran programs with your distribution -(because, perhaps, they're picking up their old version of the `gcc' -command, which does not recognize Fortran programs), and assume that -your binaries (or, more generally, GNU Fortran distributions in -general) are broken, at least for their system. - - Finally, *please* ask for bug reports to go to you first, at least -until you're sure your distribution is widely used and has been well -tested. This especially goes for those of you making any changes to -the `g77' sources to port `g77', e.g. to OS/2. -`fortran@gnu.ai.mit.edu' has received a fair amount 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. - - -File: g77.info, Node: Settings, Prev: Distributing Binaries, Up: Installation - -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'. - -* Menu: - -* Maximum Stackable Size:: Large arrays are forced off the stack frame. -* Floating-point Bit Patterns:: Possible programs building cross-compiler. -* Large Initialization:: Large arrays with `DATA' initialization. -* Alpha Problems:: Problems with 64-bit systems like Alphas. - - -File: g77.info, Node: Maximum Stackable Size, Next: Floating-point Bit Patterns, Up: Settings - -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). - - -File: g77.info, Node: Floating-point Bit Patterns, Next: Large Initialization, Prev: Maximum Stackable Size, Up: Settings - -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/3.1415926535/'.) - - -File: g77.info, Node: Large Initialization, Next: Alpha Problems, Prev: Floating-point Bit Patterns, Up: Settings - -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 noticably slower than -linear performance would suggest. - - -File: g77.info, Node: Alpha Problems, Prev: Large Initialization, Up: Settings - -Alpha Problems --------------- - - `g77' might warn when it is 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). This is because `g77' is known to not -work properly on such configurations, although the reasons for this are -not fully explored. This is expected to be fixed at 0.6, at which -point the warning would be dropped. (The reason the unexplored -problems are expected to be fixed at 0.6 is because some known internal -design problems `g77' has, which reduce portability and the ability to -configure it as a cross-compiler, are presumed to be at least partly -responsible for the problems being encountered on the Alpha. The -problems remain unexplored partly because the known problems exist and -are scheduled to be addressed anyway. Plus, the `g77' maintainer does -not yet possess an Alpha workstation of his own.) - - -File: g77.info, Node: Debugging and Interfacing, Next: Collected Fortran Wisdom, Prev: Installation, Up: Top - -Debugging and Interfacing -************************* - - GNU Fortran currently generates code that is object-compatible with -the `f2c' converter. Also, it avoids limitations in the current GBE, -such as the inability to generate a procedure with multiple entry -points, by generating code that is structured differently (in terms of -procedure names, scopes, arguments, and so on) than might be expected. - - As a result, writing code in other languages that calls on, is -called by, or shares in-memory data with `g77'-compiled code generally -requires some understanding of the way `g77' compiles code for various -constructs. - - Similarly, using a debugger to debug `g77'-compiled code, even if -that debugger supports native Fortran debugging, generally requires -this sort of information. - - This section describes some of the basic information on how `g77' -compiles code for constructs involving interfaces to other languages -and to debuggers. - - *Caution:* Much or all of this information pertains to only the -current release of `g77', sometimes even to using certain compiler -options with `g77' (such as `-fno-f2c'). Do not write code that -depends on this information without clearly marking said code as -nonportable and subject to review for every new release of `g77'. This -information is provided primarily to make debugging of code generated -by this particular release of `g77' easier for the user, and partly to -make writing (generally nonportable) interface code easier. Both of -these activities require tracking changes in new version of `g77' as -they are installed, because new versions can change the behaviors -described in this section. - -* Menu: - -* Names:: Naming of user-defined variables, procedures, etc. -* Main Program Unit:: How `g77' compiles a main program unit. -* Arrays:: Dealing with (possibly multi-dimensional) arrays. -* Procedures:: How `g77' constructs parameter lists - for procedures. -* Adjustable Arrays:: Special consideration for adjustable arrays. -* Alternate Returns:: How `g77' handles alternate returns. -* Functions:: Functions returning floating-point or character data. -* Common Blocks:: Accessing common variables while debugging. -* Local Equivalence Areas:: Accessing `EQUIVALENCE' while debugging. -* Alternate Entry Points:: How `g77' implements alternate `ENTRY'. -* Assigned Statement Labels:: How `g77' handles `ASSIGN'. - - -File: g77.info, Node: Names, Next: Main Program Unit, Up: Debugging and Interfacing - -Names -===== - - Fortran permits each implementation to decide how to represent names -as far as how they're seen in other contexts, such as debuggers and -when interfacing to other languages, and especially as far as how -casing is handled. - - External names--names of entities that are public, or "accessible", -to all modules in a program--normally have an underscore (`_') appended -by `g77', to generate code that is compatible with f2c. External names -include names of Fortran things like common blocks, external procedures -(subroutines and functions, but not including statement functions, -which are internal procedures), and entry point names. - - However, use of the `-fno-underscoring' option disables this kind of -transformation of external names (though inhibiting the transformation -certainly improves the chances of colliding with incompatible externals -written in other languages--but that might be intentional. - - When `-funderscoring' is in force, any name (external or local) that -already has at least one underscore in it is implemented by `g77' by -appending two underscores. External names are changed this way for -`f2c' compatibility. Local names are changed this way to avoid -collisions with external names that are different in the source -code--`f2c' does the same thing, but there's no compatibility issue -there except for user expectations while debugging. - - For example: - - Max_Cost = 0 - -Here, a user would, in the debugger, refer to this variable using the -name `max_cost__' (or `MAX_COST__' or `Max_Cost__', as described below). -(We hope to improve `g77' in this regard in the future--don't write -scripts depending on this behavior! Also, consider experimenting with -the `-fno-underscoring' option to try out debugging without having to -massage names by hand like this.) - - `g77' provides a number of command-line options that allow the user -to control how case mapping is handled for source files. The default -is the traditional UNIX model for Fortran compilers--names are mapped -to lower case. Other command-line options can be specified to map -names to upper case, or to leave them exactly as written in the source -file. - - For example: - - Foo = 3.14159 - -Here, it is normally the case that the variable assigned will be named -`foo'. This would be the name to enter when using a debugger to access -the variable. - - However, depending on the command-line options specified, the name -implemented by `g77' might instead be `FOO' or even `Foo', thus -affecting how debugging is done. - - Also: - - Call Foo - -This would normally call a procedure that, if it were in a separate C -program, be defined starting with the line: - - void foo_() - -However, `g77' command-line options could be used to change the casing -of names, resulting in the name `FOO_' or `Foo_' being given to the -procedure instead of `foo_', and the `-fno-underscoring' option could -be used to inhibit the appending of the underscore to the name. - - -File: g77.info, Node: Main Program Unit, Next: Arrays, Prev: Names, Up: Debugging and Interfacing - -Main Program Unit (PROGRAM) -=========================== - - When `g77' compiles a main program unit, it gives it the public -procedure name `MAIN__'. The `libf2c' library has the actual `main()' -procedure as is typical of C-based environments, and it is this -procedure that performs some initial start-up activity and then calls -`MAIN__'. - - Generally, `g77' and `libf2c' are designed so that you need not -include a main program unit written in Fortran in your program--it can -be written in C or some other language. Especially for I/O handling, -this is the case, although `g77-0.5.16' includes a bug fix for `libf2c' -that solved a problem with using the `OPEN' statement as the first -Fortran I/O activity in a program without a Fortran main program unit. - - However, if you don't intend to use `g77' (or `f2c') to compile your -main program unit--that is, if you intend to compile a `main()' -procedure using some other language--you should carefully examine the -code for `main()' in `libf2c', found in the source file -`gcc/f/runtime/libF77/main.c', to see what kinds of things might need -to be done by your `main()' in order to provide the Fortran environment -your Fortran code is expecting. - - For example, `libf2c''s `main()' sets up the information used by the -`IARGC' and `GETARG' intrinsics. Bypassing `libf2c''s `main()' without -providing a substitute for this activity would mean that invoking -`IARGC' and `GETARG' would produce undefined results. - - When debugging, one implication of the fact that `main()', which is -the place where the debugged program "starts" from the debugger's point -of view, is in `libf2c' is that you won't be starting your Fortran -program at a point you recognize as your Fortran code. - - The standard way to get around this problem is to set a break point -(a one-time, or temporary, break point will do) at the entrance to -`MAIN__', and then run the program. - - After doing this, the debugger will see the current execution point -of the program as at the beginning of the main program unit of your -program. - - Of course, if you really want to set a break point at some other -place in your program and just start the program running, without first -breaking at `MAIN__', that should work fine. - |