Component specific installation instructions

Component specific installation instructions

[Rainer Orth]

Proofreading gcc/doc/install.texi, I noticed the following paragraph:

  package specific installation instructions. We provide the component 
  specific installation information in the source distribution for historical 
  reference purposes only. 

The only such installation information I could find (apart from the
libstdc++ v3 stuff) is gcc/f/g77install.texi.  (Have I overlooked something
here?)  Is any of it's contents still relevant to 3.0?  Can we merge
relavant parts into gcc/doc/install.texi and do we really want to keep this
historical stuff for the release, which might easily confuse users?

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: Component specific installation instructions

[Gerald Pfeifer]

On Fri, 8 Jun 2001, Rainer Orth wrote:
> Is any of it's contents still relevant to 3.0?

This is Toon's to decide, but...

> Can we merge relavant parts into gcc/doc/install.texi and do we really
> want to keep this historical stuff for the release, which might easily
> confuse users?

...here my answers would be: Yes (merge), and no (don't keep).

It would be great could Toon and you cooperate on addressing this before
the release. (And even if not in time for 3.0, still it makes sense for
mainline and the branch for 3.0.1!)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Component specific installation instructions

[Toon Moene]

Gerald Pfeifer wrote:

> > Can we merge relavant parts into gcc/doc/install.texi and do we really
> > want to keep this historical stuff for the release, which might easily
> > confuse users?
> 
> ...here my answers would be: Yes (merge), and no (don't keep).
> 
> It would be great could Toon and you cooperate on addressing this before
> the release. (And even if not in time for 3.0, still it makes sense for
> mainline and the branch for 3.0.1!)

I'll look into this this weekend (i.e., you'll have an answer by Monday
morning at the latest).

Thanks for pointing this out.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Component specific installation instructions

[Toon Moene]

Toon Moene wrote:

> Gerald Pfeifer wrote:
> 
> > > Can we merge relavant parts into gcc/doc/install.texi and do we really
> > > want to keep this historical stuff for the release, which might easily
> > > confuse users?
> >
> > ...here my answers would be: Yes (merge), and no (don't keep).
> >
> > It would be great could Toon and you cooperate on addressing this before
> > the release. (And even if not in time for 3.0, still it makes sense for
> > mainline and the branch for 3.0.1!)
> 
> I'll look into this this weekend (i.e., you'll have an answer by Monday
> morning at the latest).

I just committed the following patch [attached] to the branch after make
bootstrap, make install and make dvi on i686-pc-linux-gnu.  It removes
all documentation from g77install.texi and moves parts that are still
relevant to g77.texi and bugs.texi.

I'll commit a similar patch to the trunk, but there I will remove
g77install.texi completely.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
*** g77install.texi.orig	Thu Dec 21 22:24:27 2000
--- g77install.texi	Sun Jun 10 11:28:32 2001
***************
*** 1,7 ****
! @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
--- 1,7 ----
! @c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001 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 2001-06-10
  
  @include root.texi
***************
*** 11,511 ****
  @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.
--- 11,14 ----
  @cindex installing, GNU Fortran
  
! The information describing how to install @code{g77} is contained
! in the @value{which-gcc} installation procedures.
*** g77.texi.orig	Sun Jun  3 13:37:28 2001
--- g77.texi	Sun Jun 10 12:28:59 2001
***************
*** 3,7 ****
  @setfilename g77.info
  
! @set last-update 2001-06-03
  @set copyrights-g77 1995,1996,1997,1998,1999,2000,2001
  
--- 3,7 ----
  @setfilename g77.info
  
! @set last-update 2001-06-10
  @set copyrights-g77 1995,1996,1997,1998,1999,2000,2001
  
*************** result in generating the appropriate cal
*** 10389,10395 ****
  non-flushing library routines.)
  
! @xref{Always Flush Output}, for information on how to modify
! the @code{g77} source tree so that a version of @code{libg2c}
! can be built and installed with the @code{ALWAYS_FLUSH} macro defined.
  
  @node Large File Unit Numbers
--- 10389,10432 ----
  non-flushing library routines.)
  
! 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 Large File Unit Numbers
*************** If you can easily change your program to
*** 10415,10429 ****
  in the range 0 through 99, you should do so.
  
! Otherwise, see @ref{Larger File Unit Numbers}, for information on how
! to change @code{MXUNIT} in @code{libg2c} so you can build and
! install a new version of @code{libg2c} that supports the larger
! unit numbers you need.
  
! @emph{Note:} While @code{libg2c} places a limit on the range
! of Fortran file-unit numbers, the underlying library and operating
! system might impose different kinds of limits.
! For example, some systems limit the number of files simultaneously
! open by a running program.
! Information on how to increase these limits should be found
  in your system's documentation.
  
--- 10452,10490 ----
  in the range 0 through 99, you should do so.
  
! 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.
  
*************** missing features that are too much work 
*** 10795,10802 ****
  where people's opinions differ as to what is best.
  
- Information on bugs that show up when configuring, porting, building,
- or installing @code{g77} is not provided here.
- @xref{Problems Installing}.
- 
  To find out about major bugs discovered in the current release and
  possible workarounds for them, see
--- 10856,10859 ----
*************** You might be able to work around the pro
*** 11062,11068 ****
  expense of speed.
  
! @xref{Maximum Stackable Size}, for information on patching
! @code{g77} to use different criteria for placing local
! non-automatic variables and arrays on the stack.
  
  @cindex automatic arrays
--- 11119,11142 ----
  expense of speed.
  
! @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.
! @emph{Note:} While @code{libg2c} places a limit on the range
! of Fortran file-unit numbers, the underlying library and operating
! system might impose different kinds of limits.
! For example, some systems limit the number of files simultaneously
! open by a running program.
! Information on how to increase these limits should be found
! in your system's documentation.
  
  @cindex automatic arrays
*************** without exhibiting any other outward man
*** 15023,15040 ****
  
  @noindent
- @smallexample
- If the above command failed due to an unresolved reference
- to strtoul, _strtoul, bsearch, _bsearch, or similar, see
- [info -f g77 M LINKFAIL] (a node in the g77 documentation)
- for information on what causes this, how to work around
- the problem by editing $@{srcdir@}/proj.c, and what else to do.
- @end smallexample
- 
- @xref{Missing strtoul or bsearch}, for more information on
- this problem,
- which occurs only in releases of @code{g77}
- based on @code{gcc}.
- (It did not occur in @code{egcs}.)
- 
  On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
  due to a linker bug in coping with the @samp{-bbigtoc} option which
--- 15097,15100 ----
*** bugs.texi.orig	Wed May 23 19:03:24 2001
--- bugs.texi	Sun Jun 10 12:31:40 2001
***************
*** 1,3 ****
! @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.
--- 1,3 ----
! @c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
  @c This is part of the G77 manual.
  @c For copying conditions, see the file g77.texi.
***************
*** 8,14 ****
  @c Keep this the same as the dates above, since it's used
  @c in the standalone derivations of this file (e.g. BUGS).
! @set copyrights-bugs 1995,1996,1997,1998,1999,2000
  
! @set last-update-bugs 2000-11-05
  
  @include root.texi
--- 8,14 ----
  @c Keep this the same as the dates above, since it's used
  @c in the standalone derivations of this file (e.g. BUGS).
! @set copyrights-bugs 1995,1996,1997,1998,1999,2000,2001
  
! @set last-update-bugs 2001-06-10
  
  @include root.texi
*************** is available via
*** 83,98 ****
  Follow the ``Known Bugs'' link.
  
- @ifset DOC-G77
- For information on bugs that might afflict people who
- configure, port, build, and install @code{g77},
- see @ref{Problems Installing}.
- @end ifset
- 
- @ifset DOC-BUGS
- For information on bugs that might afflict people who
- configure, port, build, and install @code{g77},
- see "Problems Installing" in @file{@value{path-g77}/INSTALL}.
- @end ifset
- 
  The following information was last updated on @value{last-update-bugs}:
  
--- 83,86 ----
*************** Note that @code{g77} does display a warn
*** 168,174 ****
  notify the user before the compiler appears to hang.
  @ifset DOC-G77
! @xref{Large Initialization,,Initialization of Large Aggregate Areas},
! for information on how to change the point at which
! @code{g77} decides to issue this warning.
  @end ifset
  
--- 156,193 ----
  notify the user before the compiler appears to hang.
  @ifset DOC-G77
! 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.
  @end ifset
  

Re: Component specific installation instructions

[Gerald Pfeifer]

On Sun, 10 Jun 2001, Toon Moene wrote:
> I just committed the following patch [attached] to the branch after make
> bootstrap, make install and make dvi on i686-pc-linux-gnu.  It removes
> all documentation from g77install.texi and moves parts that are still
> relevant to g77.texi and bugs.texi.
>
> I'll commit a similar patch to the trunk, but there I will remove
> g77install.texi completely.

Cool. Our documentation really has improved quite a lot recently. :-)

Thanks a lot!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/