Go to the first, previous, next, last section, table of contents.
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).
Normally, 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 gcc.
(Normally, f2c will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
versions of f2c, or versions having certain configuration changes
to f2c internals, will produce object files that are
incompatible with g77.)
For example, a Fortran string subroutine
argument will become two arguments on the C side: a char *
and an int length.
Much of this compatibility results from the fact that
g77 uses the same run-time library,
libf2c, used by f2c,
though g77 gives its version the name libg2c
so as to avoid conflicts when linking,
installing them in the same directories,
and so on.
Other compilers might or might not generate code that
is object-compatible with libg2c and current g77,
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!
f2c Compatibility
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 f2c.
For example, this affects how REAL(KIND=1),
COMPLEX(KIND=1), and COMPLEX(KIND=2) functions are called.
With `-fno-f2c', they are
compiled as returning the appropriate gcc type
(float, __complex__ float, __complex__ double,
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---REAL(KIND=1) functions
return C's 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.
Note that 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 g77
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 g77
or 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 g77,
you might want to stick with f2c compatibility for now, and
carefully watch for any announcements about changes to the
f2c/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 f2c,
and that version probably would no longer use libf2c.
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.
(The library g77 produces will no longer be named `libg2c'
when it is no longer generally compatible with `libf2c'.
It will likely be referred to, and, if installed as a distinct
library, named libg77, or some other as-yet-unused name.)
f2c
On systems with Fortran compilers other than f2c and g77,
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 g77-compiled code.
Reasons for such incompatibilities include:
g77 to call a procedure the linker ld sees
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.
g77 to
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.