An individual Fortran source file can be compiled to an object (`*.o') file instead of to the final program executable. This allows several portions of a program to be compiled at different times and linked together whenever a new version of the program is needed. However, it introduces the issue of object compatibility across the various object files (and libraries, or `*.a' files) that are linked together to produce any particular executable file.
Object compatibility is an issue when combining, in one
program, Fortran code compiled by more than one compiler
(or more than one configuration of a compiler).
If the compilers
disagree on how to transform the names of procedures, there
will normally be errors when linking such programs.
Worse, if the compilers agree on naming, but disagree on issues
like how to pass parameters, return arguments, and lay out
COMMON areas, the earliest detected errors might be the
incorrect results produced by the program (and that assumes
these errors are detected, which is not always the case).
g77 generates code that is
object-compatible with code generated by a version of
f2c configured (with, for example, `f2c.h' definitions)
to be generally compatible with
g77 as built by
f2c will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
f2c, or versions having certain configuration changes
f2c internals, will produce object files that are
For example, a Fortran string subroutine
argument will become two arguments on the C side: a
Much of this compatibility results from the fact that
g77 uses the same run-time library,
libf2c, used by
Other compilers might or might not generate code that
is object-compatible with
libf2c and current
and some might offer such compatibility only when explicitly
selected via a command-line option to the compiler.
Note: This portion of the documentation definitely needs a lot of work!
Specifying `-fno-f2c' allows
g77 to generate, in
some cases, faster code, by not needing to allow to the possibility
of linking with code compiled by
For example, this affects how
COMPLEX(KIND=2) functions are called.
With `-fno-f2c', they are
compiled as returning the appropriate
in many configurations).
With `-ff2c' in force, they
are compiled differently (with perhaps slower run-time performance)
to accommodate the restrictions inherent in
f2c's use of K&R
C as an intermediate language---
double type, while
COMPLEX functions return
void and use an extra argument pointing to a place for the functions to
return their values.
It is possible that, in some cases, leaving `-ff2c' in force might produce faster code than using `-fno-f2c'. Feel free to experiment, but remember to experiment with changing the way entire programs and their Fortran libraries are compiled at a time, since this sort of experimentation affects the interface of code generated for a Fortran source file--that is, it affects object compatibility.
f2c compatibility is a fairly static target to achieve,
though not necessarily perfectly so, since, like
g77, it is
still being improved.
However, specifying `-fno-f2c' causes
to generate code that will probably be incompatible with code
generated by future versions of
g77 when the same option
is in force.
You should make sure you are always able to recompile complete
programs from source code when upgrading to new versions of
f2c, especially when using options such as `-fno-f2c'.
Therefore, if you are using
g77 to compile libraries and other
object files for possible future use and you don't want to require
recompilation for future use with subsequent versions of
you might want to stick with
f2c compatibility for now, and
carefully watch for any announcements about changes to the
libf2c interface that might affect existing programs
(thus requiring recompilation).
It is probable that a future version of
g77 will not,
by default, generate object files compatible with
and that version probably would no longer use
If you expect to depend on this compatibility in the
long term, use the options `-ff2c -ff2c-library' when compiling
all of the applicable code.
This should cause future versions of
g77 either to produce
compatible code (at the expense of the availability of some features and
performance), or at the very least, to produce diagnostics.
On systems with Fortran compilers other than
code compiled by
g77 is not expected to work
well with code compiled by the native compiler.
(This is true for
f2c-compiled objects as well.)
Libraries compiled with the native compiler probably will have
to be recompiled with
g77 to be used with
Reasons for such incompatibilities include:
g77to call a procedure the linker
ldsees given the name `_foo_', while the apparently corresponding statement `SUBROUTINE FOO' might be compiled by the native compiler to define the linker-visible name `_foo', or `_FOO_', and so on.
g77to transform procedure names the same way a native compiler does is not usually a good idea--unless some effort has been made to ensure that, aside from the way the two compilers transform procedure names, everything else about the way they generate code for procedure interfaces is identical.
Go to the first, previous, next, last section, table of contents.