Other Compilers

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!

Dropping 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.)

Compilers Other Than 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:

• There might be differences in the way names of Fortran procedures are translated for use in the system's object-file format. For example, the statement `CALL FOO' might be compiled by 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.
• There might be subtle type mismatches which cause subroutine arguments and function return values to get corrupted. This is why simply getting 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.
• Native compilers use libraries of private I/O routines which will not be available at link time unless you have the native compiler--and you would have to explicitly ask for them. For example, on the Sun you would have to add `-L/usr/lang/SCx.x -lF77 -lV77' to the link command.