Go to the first, previous, next, last section, table of contents.

# 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: When speed is more important.
- Compilers Other Than f2c: Interoperation with code from other compilers.

## 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.

Go to the first, previous, next, last section, table of contents.