g77install.texi

gcc-2.95.3 Linux下最常用的C编译器

@code{makeinfo} is part of the GNU @code{texinfo} package;
@code{makeinfo} version @value{version-makeinfo}
is distributed as part of
GNU @code{texinfo} version @value{version-texinfo}.

@code{makeinfo} is not needed in the typical case of
installing @code{gcc} and @code{g77}.
@xref{Missing tools?}, for information on when it
might be needed and how to work around not having it.

An up-to-date version of GNU @code{makeinfo} is still convenient
when obtaining a new version of a GNU distribution such as
@code{gcc} or @code{g77},
as it allows you to obtain the @file{.diff.gz} file
instead of the entire @file{.tar.gz} distribution
(assuming you have installed @code{patch}).

@item @code{patch}
The version of GNU @code{patch} used to develop this release
is @value{version-patch}.

Beginning with @code{g77} version 0.5.23, it is no longer
necessary to patch the @code{gcc} back end to build @code{g77}.

An up-to-date version of GNU @code{patch} is still convenient
when obtaining a new version of a GNU distribution such as
@code{gcc} or @code{g77},
as it allows you to obtain the @file{.diff.gz} file
instead of the entire @file{.tar.gz} distribution
(assuming you have installed the tools needed
to rebuild derived files, such as @code{makeinfo}).
@end table

@end ifclear

@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

@ifset OMIT-FSF-G77
This information does not apply to
the @value{which-g77} version of @code{g77},
@end ifset

@ifclear OMIT-FSF-G77
On SunOS4 systems, linking the @code{f771} program used to
produce an error message concerning an undefined symbol named
@samp{_strtoul}, because the @code{strtoul} library function
is not provided on that system.

Other systems have, in the past, been reported to not provide
their own @code{strtoul} or @code{bsearch} function.

Some versions @code{g77} tried to default to providing bare-bones
versions of @code{bsearch} and @code{strtoul} automatically,
but every attempt at this has failed for at least one kind of system.

To limit the failures to those few systems actually missing the
required routines, the bare-bones versions are still provided,
in @file{@value{path-g77}/proj.c},
if the appropriate macros are defined.
These are @code{NEED_BSEARCH} for @code{bsearch} and
@code{NEED_STRTOUL} for @code{NEED_STRTOUL}.

Therefore, if you are sure your system is missing
@code{bsearch} or @code{strtoul} in its library,
define the relevant macro(s) before building @code{g77}.
This can be done by editing @file{@value{path-g77}/proj.c} and inserting
either or both of the following @samp{#define} statements
before the comment shown:

@smallexample
/* Insert #define statements here.  */

#define NEED_BSEARCH
#define NEED_STRTOUL
@end smallexample

Then, continue configuring and building @code{g77} as usual.

Or, you can define these on the @code{make} command line.
To build with the bundled @code{cc} on SunOS4, for example, try:
@smallexample
make bootstrap BOOT_CFLAGS='-O2 -g -DNEED_STRTOUL'
@end smallexample

If you then encounter problems compiling @file{@value{path-g77}/proj.c},
it might be due to a discrepancy between how @code{bsearch}
or @code{strtoul} are defined by that file and how they're
declared by your system's header files.

In that case, you'll have to use some basic knowledge of C
to work around the problem, perhaps by editing @file{@value{path-g77}/proj.c}
somewhat.

@end ifclear

@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}.
It might also occur when building within @code{egcs}.
@ifset DOC-G77
@xref{LINKFAIL}.
@end ifset

@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 is 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