fort77(1p) — Linux manual page


FORT77(1P)              POSIX Programmer's Manual             FORT77(1P)

PROLOG         top

       This manual page is part of the POSIX Programmer's Manual.  The
       Linux implementation of this interface may differ (consult the
       corresponding Linux manual page for details of Linux behavior),
       or the interface may not be implemented on Linux.

NAME         top

       fort77 — FORTRAN compiler (FORTRAN)

SYNOPSIS         top

       fort77 [-c] [-g] [-L directory]... [-O optlevel] [-o outfile] [-s]
           [-w] operand...

DESCRIPTION         top

       The fort77 utility is the interface to the FORTRAN compilation
       system; it shall accept the full FORTRAN-77 language defined by
       the ANSI X3.9‐1978 standard. The system conceptually consists of
       a compiler and link editor. The files referenced by operands are
       compiled and linked to produce an executable file. It is
       unspecified whether the linking occurs entirely within the
       operation of fort77; some implementations may produce objects
       that are not fully resolved until the file is executed.

       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

       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:

       and that the bits specified by the umask of the process shall be

OPTIONS         top

       The fort77 utility shall conform to the Base Definitions volume
       of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines, except

        *  The -l library operands have the format of options, but their
           position within a list of operands affects the order in which
           libraries are searched.

        *  The order of specifying the multiple -L options is

        *  Conforming applications shall specify each option separately;
           that is, grouping option letters (for example, -cg) need not
           be recognized by all implementations.

       The following options shall be supported:

       -c        Suppress the link-edit phase of the compilation, and do
                 not remove any object files that are produced.

       -g        Produce symbolic information in the object or
                 executable files; the nature of this information is
                 unspecified, and may be modified by implementation-
                 defined interactions with other options.

       -s        Produce object or executable files, or both, from which
                 symbolic and other information not required for proper
                 execution using the exec family of functions defined in
                 the System Interfaces volume of POSIX.1‐2017 has been
                 removed (stripped).  If both -g and -s options are
                 present, the action taken is unspecified.

       -o outfile
                 Use the pathname outfile, instead of the default a.out,
                 for the executable file produced. If the -o option is
                 present with -c, the result is unspecified.

       -L directory
                 Change the algorithm of searching for the libraries
                 named in -l operands to look in the directory named by
                 the directory pathname before looking in the usual
                 places. Directories named in -L options shall be
                 searched in the specified order. At least ten instances
                 of this option shall be supported in a single fort77
                 command invocation. If a directory specified by a -L
                 option contains a file named libf.a, the results are

       -O optlevel
                 Specify the level of code optimization. If the optlevel
                 option-argument is the digit '0', all special code
                 optimizations shall be disabled. If it is the digit
                 '1', the nature of the optimization is unspecified. If
                 the -O option is omitted, the nature of the system's
                 default optimization is unspecified. It is unspecified
                 whether code generated in the presence of the -O 0
                 option is the same as that generated when -O is
                 omitted. Other optlevel values may be supported.

       -w        Suppress warnings.

       Multiple instances of -L options can be specified.

OPERANDS         top

       An operand is either in the form of a pathname or the form -l
       library.  At least one operand of the pathname form shall be
       specified. The following operands shall be supported:

       file.f    The pathname of a FORTRAN source file to be compiled
                 and optionally passed to the link editor. The filename
                 operand shall be of this form if the -c option is used.

       file.a    A library of object files typically produced by ar, and
                 passed directly to the link editor. Implementations may
                 recognize implementation-defined suffixes other than .a
                 as denoting object file libraries.

       file.o    An object file produced by fort77 -c and passed
                 directly to the link editor. Implementations may
                 recognize implementation-defined suffixes other than .o
                 as denoting object files.

       The processing of other files is implementation-defined.

       -l library
                 (The letter ell.) Search the library named:


                 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.

STDIN         top

       Not used.

INPUT FILES         top

       The input file shall be one of the following: a text file
       containing FORTRAN source code; an object file in the format
       produced by fort77 -c; or a library of object files, in the
       format produced by archiving zero or more object files, using ar.
       Implementations may supply additional utilities that produce
       files in these formats. Additional input files are

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


       The following environment variables shall affect the execution of

       LANG      Provide a default value for the internationalization
                 variables that are unset or null. (See the Base
                 Definitions volume of POSIX.1‐2017, Section 8.2,
                 Internationalization Variables for the precedence of
                 internationalization variables used to determine the
                 values of locale categories.)

       LC_ALL    If set to a non-empty string value, override the values
                 of all the other internationalization variables.

       LC_CTYPE  Determine the locale for the interpretation of
                 sequences of bytes of text data as characters (for
                 example, single-byte as opposed to multi-byte
                 characters in arguments and input files).

                 Determine the locale that should be used to affect the
                 format and contents of diagnostic messages written to
                 standard error.

       NLSPATH   Determine the location of message catalogs for the
                 processing of LC_MESSAGES.

       TMPDIR    Determine the pathname that should override the default
                 directory for temporary files, if any.



STDOUT         top

       Not used.

STDERR         top

       The standard error shall be used only for diagnostic messages.
       If more than one file operand ending in .f (or possibly other
       unspecified suffixes) is given, for each such file:

           "%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

OUTPUT FILES         top

       Object files, listing files, and executable files shall be
       produced in unspecified formats.


   Standard Libraries
       The fort77 utility shall recognize the following -l operand for
       the standard library:

       -l f      This library contains all functions referenced in the
                 ANSI X3.9‐1978 standard. This operand shall not be
                 required to be present to cause a search of this

       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.

   External Symbols
       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.

EXIT STATUS         top

       The following exit values shall be returned:

        0    Successful compilation or link edit.

       >0    An error occurred.


       When fort77 encounters a compilation error, it shall write a
       diagnostic to standard error and continue to compile other source
       code operands. It shall return a non-zero exit status, but it is
       implementation-defined whether an object module is created. If
       the link edit is unsuccessful, a diagnostic message shall be
       written to standard error, and fort77 shall exit with a non-zero

       The following sections are informative.



EXAMPLES         top

       The following usage example compiles xyz.f and creates the
       executable file foo:

           fort77 -o foo xyz.f

       The following example compiles xyz.f and creates the object file

           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

RATIONALE         top

       The name of this utility was chosen as fort77 to parallel the
       renaming of the C compiler. The name f77 was not chosen to avoid
       problems with historical implementations. The ANSI X3.9‐1978
       standard was selected as a normative reference because the
       ISO/IEC version of FORTRAN-77 has been superseded by the
       ISO/IEC 1539:1991 standard.

       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

       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

       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

       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:

       -O 0      No optimization.

       -O 1      Some level of optimization.

       -O n      Other, unspecified levels of optimization.

       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.


       Future versions of this standard may withdraw this utility. There
       are implementations of compilers that conform to much more recent
       versions of the FORTRAN programming language. Since there is no
       active FORTRAN binding to POSIX.1‐2008, this standard does not
       need to specify any compiler.

SEE ALSO         top

       ar(1p), asa(1p), c99(1p), umask(1p)

       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(1p)

COPYRIGHT         top

       Portions of this text are reprinted and reproduced in electronic
       form from IEEE Std 1003.1-2017, Standard for Information
       Technology -- Portable Operating System Interface (POSIX), The
       Open Group Base Specifications Issue 7, 2018 Edition, Copyright
       (C) 2018 by the Institute of Electrical and Electronics
       Engineers, Inc and The Open Group.  In the event of any
       discrepancy between this version and the original IEEE and The
       Open Group Standard, the original IEEE and The Open Group
       Standard is the referee document. The original Standard can be
       obtained online at .

       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 .

IEEE/The Open Group               2017                        FORT77(1P)

Pages that refer to this page: ar(1p)asa(1p)ctags(1p)strip(1p)