fort77 [-c] [-g] [-L directory]... [-O optlevel] [-o outfile] [-s]
[-w] operand...
If the -c option is present, for all pathname operands of the form file.f, the files:
$(basename pathname.f).o
shall be created or overwritten as the result of successful compilation. If the -c option is not specified, it is unspecified whether such .o files are created or deleted for the file.f operands.
If there are no options that prevent link editing (such as -c) and all operands compile and link without error, the resulting executable file shall be written into the file named by the -o option (if present) or to the file a.out. The executable file shall be created as specified in the System Interfaces volume of POSIX.1-2017, except that the file permissions shall be set to: S_IRWXO | S_IRWXG | S_IRWXU
and that the bits specified by the umask of the process shall be cleared.
The following options shall be supported:
Multiple instances of -L options can be specified.
The processing of other files is implementation-defined.
liblibrary.a
A library is searched when its name is encountered, so the placement of a -l operand is significant. Several standard libraries can be specified in this manner, as described in the EXTENDED DESCRIPTION section. Implementations may recognize implementation-defined suffixes other than .a as denoting libraries.
A <tab> encountered within the first six characters on a line of source code shall cause the compiler to interpret the following character as if it were the seventh character on the line (that is, in column 7).
"%s:\n", <file>
may be written to allow identification of the diagnostic message with the appropriate input file.
This utility may produce warning messages about certain conditions that do not warrant returning an error (non-zero) exit value.
The fort77 utility shall recognize the following -l operand for the standard library:
In the absence of options that inhibit invocation of the link editor, such as -c, the fort77 utility shall cause the equivalent of a -l f operand to be passed to the link editor as the last -l operand, causing it to be searched after all other object files and libraries are loaded.
It is unspecified whether the library libf.a exists as a regular file. The implementation may accept as -l operands names of objects that do not exist as regular files.
The FORTRAN compiler and link editor shall support the significance of external symbols up to a length of at least 31 bytes; case folding is permitted. The action taken upon encountering symbols exceeding the implementation-defined maximum symbol length is unspecified.
The compiler and link editor shall support a minimum of 511 external symbols per source or object file, and a minimum of 4095 external symbols total. A diagnostic message is written to standard output if the implementation-defined limit is exceeded; other actions are unspecified.
The following sections are informative.
fort77 -o foo xyz.f
The following example compiles xyz.f and creates the object file xyz.o:
fort77 -c xyz.f
The following example compiles xyz.f and creates the executable file a.out:
fort77 xyz.f
The following example compiles xyz.f, links it with b.o, and creates the executable a.out:
fort77 xyz.f b.o
The file inclusion and symbol definition #define mechanisms used by the c99 utility were not included in this volume of POSIX.1-2017---even though they are commonly implemented---since there is no requirement that the FORTRAN compiler use the C preprocessor.
The -onetrip option was not included in this volume of POSIX.1-2017, even though many historical compilers support it, because it is derived from FORTRAN-66; it is an anachronism that should not be perpetuated.
Some implementations produce compilation listings. This aspect of FORTRAN has been left unspecified because there was controversy concerning the various methods proposed for implementing it: a -V option overlapped with historical vendor practice and a naming convention of creating files with .l suffixes collided with historical lex file naming practice.
There is no -I option in this version of this volume of POSIX.1-2017 to specify a directory for file inclusion. An INCLUDE directive has been a part of the Fortran-90 discussions, but an interface supporting that standard is not in the current scope.
It is noted that many FORTRAN compilers produce an object module even when compilation errors occur; during a subsequent compilation, the compiler may patch the object module rather than recompiling all the code. Consequently, it is left to the implementor whether or not an object file is created.
A reference to MIL-STD-1753 was removed from an early proposal in response to a request from the POSIX FORTRAN-binding standard developers. It was not the intention of the standard developers to require certification of the FORTRAN compiler, and IEEE Std 1003.9-1992 does not specify the military standard or any special preprocessing requirements. Furthermore, use of that document would have been inappropriate for an international standard.
The specification of optimization has been subject to changes through early proposals. At one time, -O and -N were Booleans: optimize and do not optimize (with an unspecified default). Some historical practice led this to be changed to:
It is not always clear whether ``good code generation'' is the same thing as optimization. Simple optimizations of local actions do not usually affect the semantics of a program. The -O 0 option has been included to accommodate the very particular nature of scientific calculations in a highly optimized environment; compilers make errors. Some degree of optimization is expected, even if it is not documented here, and the ability to shut it off completely could be important when porting an application. An implementation may treat -O 0 as ``do less than normal'' if it wishes, but this is only meaningful if any of the operations it performs can affect the semantics of a program. It is highly dependent on the implementation whether doing less than normal is logical. It is not the intent of the -O 0 option to ask for inefficient code generation, but rather to assure that any semantically visible optimization is suppressed.
The specification of standard library access is consistent with the C compiler specification. Implementations are not required to have /usr/lib/libf.a, as many historical implementations do, but if not they are required to recognize f as a token.
External symbol size limits are in normative text; conforming applications need to know these limits. However, the minimum maximum symbol length should be taken as a constraint on a conforming application, not on an implementation, and consequently the action taken for a symbol exceeding the limit is unspecified. The minimum size for the external symbol table was added for similar reasons.
The CONSEQUENCES OF ERRORS section clearly specifies the behavior of the compiler when compilation or link-edit errors occur. The behavior of several historical implementations was examined, and the choice was made to be silent on the status of the executable, or a.out, file in the face of compiler or linker errors. If a linker writes the executable file, then links it on disk with lseek()s and write()s, the partially linked executable file can be left on disk and its execute bits turned off if the link edit fails. However, if the linker links the image in memory before writing the file to disk, it need not touch the executable file (if it already exists) because the link edit fails. Since both approaches are historical practice, a conforming application shall rely on the exit status of fort77, rather than on the existence or mode of the executable file.
The -g and -s options are not specified as mutually-exclusive. Historically, these two options have been mutually-exclusive, but because both are so loosely specified, it seemed appropriate to leave their interaction unspecified.
The requirement that conforming applications specify compiler options separately is to reserve the multi-character option name space for vendor-specific compiler options, which are known to exist in many historical implementations. Implementations are not required to recognize, for example, -gc as if it were -g -c; nor are they forbidden from doing so. The SYNOPSIS shows all of the options separately to highlight this requirement on applications.
Echoing filenames to standard error is considered a diagnostic message because it would otherwise be difficult to associate an error message with the erring file. They are described with ``may'' to allow implementations to use other methods of identifying files and to parallel the description in c99.
The Base Definitions volume of POSIX.1-2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
The System Interfaces volume of POSIX.1-2017, exec
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .