| @c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc. |
| @c This is part of the G77 manual. |
| @c For copying conditions, see the file g77.texi. |
| |
| @set last-update-install 2000-12-21 |
| |
| @include root.texi |
| |
| @node Installation |
| @chapter Installing GNU Fortran |
| @cindex installing, GNU Fortran |
| |
| The following information describes how to install @code{g77}. |
| |
| Note that, for users of the @value{which-g77} version of @code{g77}, |
| much of the information is obsolete, |
| and is superseded by the |
| @value{which-gcc} installation procedures. |
| Such information is accordingly omitted and flagged as such. |
| |
| @ifset DEVELOPMENT |
| @emph{Warning:} The information below is still under development, |
| and might not accurately reflect the @code{g77} code base |
| of which it is a part. |
| Efforts are made to keep it somewhat up-to-date, |
| but they are particularly concentrated |
| on any version of this information |
| that is distributed as part of a @emph{released} @code{g77}. |
| |
| In particular, while this information is intended to apply to |
| the @value{which-g77} version of @code{g77}, |
| only an official @emph{release} of that version |
| is expected to contain documentation that is |
| most consistent with the @code{g77} product in that version. |
| @end ifset |
| |
| The following information was last updated on @value{last-update-install}: |
| |
| @menu |
| * Prerequisites:: Make sure your system is ready for @code{g77}. |
| * Problems Installing:: Known trouble areas. |
| * Settings:: Changing @code{g77} internals before building. |
| * Quick Start:: The easier procedure for non-experts. |
| * Complete Installation:: For experts, or those who want to be: the details. |
| * Distributing Binaries:: If you plan on distributing your @code{g77}. |
| @end menu |
| |
| @node Prerequisites |
| @section Prerequisites |
| @cindex prerequisites |
| |
| For users of the @value{which-g77} version of @code{g77}, |
| this information is superseded by the |
| @value{which-gcc} installation instructions. |
| |
| @node Problems Installing |
| @section Problems Installing |
| @cindex problems installing |
| @cindex installation problems |
| |
| 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. |
| |
| @xref{Installation Problems,,,gcc,Using and Porting GNU CC}, |
| for more information on installation problems that can afflict |
| either @code{gcc} or @code{g77}. |
| |
| @menu |
| * General Problems:: Problems afflicting most or all systems. |
| * System-specific Problems:: Problems afflicting particular systems. |
| * Cross-compiler Problems:: Problems afflicting cross-compilation setups. |
| @end menu |
| |
| @node General Problems |
| @subsection General Problems |
| |
| These problems can occur on most or all systems. |
| |
| @menu |
| * GNU C Required:: Why even ANSI C is not enough. |
| * Patching GNU CC:: Why @code{gcc} needn't be patched. |
| * Building GNU CC Necessary:: Why you can't build @emph{just} Fortran. |
| * Missing strtoul or bsearch:: When linking @code{f771} fails. |
| * Cleanup Kills Stage Directories:: For @code{g77} developers. |
| * LANGUAGES Macro Ignored:: Sometimes @code{LANGUAGES} is ignored. |
| @end menu |
| |
| @node GNU C Required |
| @subsubsection GNU C Required |
| @cindex GNU C required |
| @cindex requirements, GNU C |
| |
| Compiling @code{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 @code{gcc} |
| installed to build @code{g77}. |
| As long as you have a working C compiler, you can use a |
| ``bootstrap'' build to automate the process of first building |
| @code{gcc} using the working C compiler you have, then building |
| @code{g77} and rebuilding @code{gcc} using that just-built @code{gcc}, |
| and so on. |
| |
| @node Patching GNU CC |
| @subsubsection Patching GNU CC |
| @cindex patch files |
| @cindex GBE |
| |
| @code{g77} no longer requires application of a patch file |
| to the @code{gcc} compiler tree. |
| In fact, no such patch file is distributed with @code{g77}. |
| This is as of version 0.5.23 |
| and @code{egcs} version 1.0. |
| |
| @node Building GNU CC Necessary |
| @subsubsection Building GNU CC Necessary |
| @cindex @code{gcc}, building |
| @cindex building gcc |
| |
| It should be possible to build the runtime without building @code{cc1} |
| and other non-Fortran items, but, for now, an easy way to do that |
| is not yet established. |
| |
| @node Missing strtoul or bsearch |
| @subsubsection Missing strtoul or bsearch |
| @cindex bsearch |
| @cindex _bsearch |
| @cindex strtoul |
| @cindex _strtoul |
| @cindex undefined reference (_bsearch) |
| @cindex undefined reference (_strtoul) |
| @cindex f771, linking error for |
| @cindex linking error for f771 |
| @cindex @code{ld}, error linking f771 |
| @cindex @code{ld}, can't find _bsearch |
| @cindex @code{ld}, can't find _strtoul |
| @cindex SunOS4 |
| |
| This information does not apply to |
| the @value{which-g77} version of @code{g77}, |
| |
| @node Cleanup Kills Stage Directories |
| @subsubsection Cleanup Kills Stage Directories |
| @cindex stage directories |
| @cindex make clean |
| |
| It'd be helpful if @code{g77}'s @file{Makefile.in} or @file{Make-lang.in} |
| would create the various @file{stage@var{n}} 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 @code{g77} |
| and version 1.1 of @code{egcs}. |
| Configuration itself no longer creates any particular directories |
| that are unique to @code{g77}. |
| The build procedures in @file{Make-lang.in} take care of |
| that, on demand. |
| |
| @node LANGUAGES Macro Ignored |
| @subsubsection LANGUAGES Macro Ignored |
| @cindex @code{LANGUAGES} macro ignored |
| @cindex ignoring @code{LANGUAGES} macro |
| |
| Prior to version 0.5.23 of @code{g77} |
| and version 1.1 of @code{egcs}, |
| @code{g77} would sometimes ignore |
| the absence of @code{f77} and @code{F77} in the |
| @code{LANGUAGES} macro definition used for the |
| @code{make} command being processed. |
| |
| As of @code{g77} version 0.5.23 |
| and @code{egcs} version 1.1, |
| @code{g77} now obeys this macro |
| in all relevant situations. |
| |
| However, in versions of @code{gcc} through 2.8.1, |
| non-@code{g77} portions of @code{gcc}, |
| such as @code{g++}, |
| are known to go ahead and perform various |
| language-specific activities when their |
| respective language strings do not appear |
| in the @code{LANGUAGES} macro in effect |
| during that invocation of @code{make}. |
| |
| It is expected that these remaining problems will |
| be fixed in a future version of @code{gcc}. |
| |
| @node System-specific Problems |
| @subsection System-specific Problems |
| |
| @cindex AIX |
| A linker bug on some versions of AIX 4.1 might prevent building |
| when @code{g77} is built within @code{gcc}. |
| @xref{LINKFAIL}. |
| |
| @node Cross-compiler Problems |
| @subsection Cross-compiler Problems |
| @cindex cross-compiler, problems |
| |
| @code{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, @code{g77} can be ported to any configuration to which |
| @code{gcc}, @code{f2c}, and @code{libf2c} can be ported and made |
| to work together, aside from the known problems described in this |
| manual. |
| If you want to port @code{g77} to a particular configuration, |
| you should first make sure @code{gcc} and @code{libf2c} can be |
| ported to that configuration before focusing on @code{g77}, because |
| @code{g77} is so dependent on them. |
| |
| Even for cases where @code{gcc} and @code{libf2c} work, |
| you might run into problems with cross-compilation on certain machines, |
| for several reasons. |
| |
| @itemize @bullet |
| @item |
| There is one known bug |
| (a design bug to be fixed in 0.6) that prevents configuration of |
| @code{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. |
| |
| @item |
| @code{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. |
| |
| @item |
| Improvements to the way @code{libg2c} is built could make |
| building @code{g77} as a cross-compiler easier---for example, |
| passing and using @samp{$(LD)} and @samp{$(AR)} in the appropriate |
| ways. |
| (This was improved in the @code{egcs} version of @code{g77}, |
| especially as of version 1.1.) |
| |
| @item |
| There are still some challenges putting together the right |
| run-time libraries (needed by @code{libg2c}) for a target |
| system, depending on the systems involved in the configuration. |
| (This is a general problem with cross-compilation, and with |
| @code{gcc} in particular.) |
| @end itemize |
| |
| @node Settings |
| @section Changing Settings Before Building |
| |
| Here are some internal @code{g77} settings that can be changed |
| by editing source files in @file{@value{path-g77}/} before building. |
| |
| This information, and perhaps even these settings, represent |
| stop-gap solutions to problems people doing various ports |
| of @code{g77} have encountered. |
| As such, none of the following information is expected to |
| be pertinent in future versions of @code{g77}. |
| |
| @menu |
| * Larger File Unit Numbers:: Raising @code{MXUNIT}. |
| * Always Flush Output:: Synchronizing write errors. |
| * Maximum Stackable Size:: Large arrays forced off the stack. |
| * Floating-point Bit Patterns:: Possible programs building @code{g77} |
| as a cross-compiler. |
| * Large Initialization:: Large arrays with @code{DATA} |
| initialization. |
| * Alpha Problems Fixed:: Problems with 64-bit systems like |
| Alphas now fixed? |
| @end menu |
| |
| @node Larger File Unit Numbers |
| @subsection Larger File Unit Numbers |
| @cindex MXUNIT |
| @cindex unit numbers |
| @cindex maximum unit number |
| @cindex illegal unit number |
| @cindex increasing maximum unit number |
| |
| As distributed, whether as part of @code{f2c} or @code{g77}, |
| @code{libf2c} accepts file unit numbers only in the range |
| 0 through 99. |
| For example, a statement such as @samp{WRITE (UNIT=100)} causes |
| a run-time crash in @code{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 @code{MXUNIT} macro, which represents the maximum unit |
| number, to an appropriately higher value. |
| |
| To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your |
| @code{g77} source tree, changing the following line: |
| |
| @example |
| #define MXUNIT 100 |
| @end example |
| |
| Change the line so that the value of @code{MXUNIT} is defined to be |
| at least one @emph{greater} than the maximum unit number used by |
| the Fortran programs on your system. |
| |
| (For example, a program that does @samp{WRITE (UNIT=255)} would require |
| @code{MXUNIT} set to at least 256 to avoid crashing.) |
| |
| Then build or rebuild @code{g77} as appropriate. |
| |
| @emph{Note:} Changing this macro has @emph{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 @samp{WRITE (UNIT=100)}, |
| but the library and operating system underlying @code{libf2c} might |
| disallow it if many other files have already been opened (via @code{OPEN} or |
| implicitly via @code{READ}, @code{WRITE}, and so on). |
| Information on how to increase these other limits should be found |
| in your system's documentation. |
| |
| @node Always Flush Output |
| @subsection Always Flush Output |
| @cindex ALWAYS_FLUSH |
| @cindex synchronous write errors |
| @cindex disk full |
| @cindex flushing output |
| @cindex fflush() |
| @cindex I/O, flushing |
| @cindex output, flushing |
| @cindex writes, flushing |
| @cindex NFS |
| @cindex network file system |
| |
| Some Fortran programs require output |
| (writes) to be flushed to the operating system (under UNIX, |
| via the @code{fflush()} library call) so that errors, |
| such as disk full, are immediately flagged via the relevant |
| @code{ERR=} and @code{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). |
| |
| @code{libg2c} supports flagging write errors immediately when |
| it is built with the @code{ALWAYS_FLUSH} macro defined. |
| This results in a @code{libg2c} 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 @code{g77} you are building, you might wish to |
| modify the @code{g77} source tree so that the version of |
| @code{libg2c} is built with the @code{ALWAYS_FLUSH} macro |
| defined, enabling this behavior. |
| |
| To do this, find this line in @file{@value{path-libf2c}/f2c.h} in |
| your @code{g77} source tree: |
| |
| @example |
| /* #define ALWAYS_FLUSH */ |
| @end example |
| |
| Remove the leading @samp{/*@w{ }}, |
| so the line begins with @samp{#define}, |
| and the trailing @samp{@w{ }*/}. |
| |
| Then build or rebuild @code{g77} as appropriate. |
| |
| @node Maximum Stackable Size |
| @subsection Maximum Stackable Size |
| @vindex FFECOM_sizeMAXSTACKITEM |
| @cindex code, stack variables |
| @cindex maximum stackable size |
| @cindex stack, allocation |
| @cindex segmentation violation |
| @code{g77}, on most machines, puts many variables and arrays on the stack |
| where possible, and can be configured (by changing |
| @code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/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). |
| |
| @emph{Note:} Putting more variables and arrays on the stack |
| might cause problems due to system-dependent limits on stack size. |
| Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no |
| effect on automatic variables and arrays. |
| @xref{But-bugs}, for more information. |
| |
| @node Floating-point Bit Patterns |
| @subsection Floating-point Bit Patterns |
| |
| @cindex cross-compiler, building |
| @cindex floating-point bit patterns |
| @cindex bit patterns |
| The @code{g77} build will crash if an attempt is made to build |
| it as a cross-compiler |
| for a target when @code{g77} cannot reliably determine the bit pattern of |
| floating-point constants for the target. |
| Planned improvements for version 0.6 of @code{g77} |
| will give it the capabilities it needs to not have to crash the build |
| but rather generate correct code for the target. |
| (Currently, @code{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 @samp{EQUIVALENCE (I,R)} and @samp{DATA R/9.43578/}.) |
| |
| @node Large Initialization |
| @subsection Initialization of Large Aggregate Areas |
| |
| @cindex speed, of compiler |
| @cindex slow compiler |
| @cindex memory utilization |
| @cindex large initialization |
| @cindex aggregate initialization |
| A warning message is issued when @code{g77} sees code that provides |
| initial values (e.g. via @code{DATA}) to an aggregate area (@code{COMMON} |
| or @code{EQUIVALENCE}, or even a large enough array or @code{CHARACTER} |
| variable) |
| that is large enough to increase @code{g77}'s compile time by roughly |
| a factor of 10. |
| |
| This size currently is quite small, since @code{g77} |
| currently has a known bug requiring too much memory |
| and time to handle such cases. |
| In @file{@value{path-g77}/data.c}, the macro |
| @code{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 @code{g77} for |
| the change to take effect. |
| |
| Note that, as of version 0.5.18, improvements have |
| reduced the scope of the problem for @emph{sparse} |
| initialization of large arrays, especially those |
| with large, contiguous uninitialized areas. |
| However, the warning is issued at a point prior to |
| when @code{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. |
| |
| @node Alpha Problems Fixed |
| @subsection Alpha Problems Fixed |
| |
| @cindex Alpha, support |
| @cindex 64-bit systems |
| @code{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 @code{g77} was known to not work |
| properly on such configurations. |
| |
| As of version 0.5.20, @code{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. |
| |
| @node Quick Start |
| @section Quick Start |
| @cindex quick start |
| |
| For users of the @value{which-g77} version of @code{g77}, |
| this information is superseded by the |
| @value{which-gcc} installation instructions. |
| |
| @node Complete Installation |
| @section Complete Installation |
| |
| For users of the @value{which-g77} version of @code{g77}, |
| this information is superseded by the |
| @value{which-gcc} installation instructions. |
| |
| @node Distributing Binaries |
| @section Distributing Binaries |
| @cindex binaries, distributing |
| @cindex code, distributing |
| |
| For users of the @value{which-g77} version of @code{g77}, |
| this information is superseded by the |
| @value{which-gcc} installation instructions. |