FORT77(1P)

✨ FORT77(1P) ✨

okay bestie, so this one is from the POSIX Programmer's Manual (the 1P in the name is giving "POSIX utility page", iykyk).

⚠️ heads up before we go anywhere: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so pls go consult the corresponding Linux manual page for the deets), or honestly the interface may not be implemented on Linux at all. 💀 Not us finding out the hard way.

---

🌸 PROLOG 🌸

Literally just what I said up top, but in its own little section, so here it is again fr:</p>

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 🎀

fort77 — the FORTRAN compiler, FORTRAN flavor. that's it. that's the whole name section. 💅

---

🦋 SYNOPSIS 🦋

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

yes queen, look at that tiny little usage line. so much power in so few characters. ✨

---

💖 DESCRIPTION 💖

okay so here's the vibe: the fort77 utility is the interface to the FORTRAN compilation system. And not just any FORTRAN — it shall accept the full FORTRAN-77 language as defined by the ANSI X3.9‐1978 standard. iconic. historic. slay.

The system conceptually consists of a compiler and a link editor. The files referenced by the operands get compiled and linked to produce an executable file.

and here's the sneaky part bestie: 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. 🙈 so like, don't @ us if your binary is doing mysterious things at runtime.

---

now, the -c option, which is the "just compile, don't link" girlie:

If the -c option is present, then 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. (so like… maybe they exist, maybe they don't. we simply do not know. 💀)

---

and the linking finale:

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. 💅 (yes, it really does just hand out rwxrwxrwx energy like that. permissions? never heard of her.)

---

✨ OPTIONS ✨

okay bestie, buckle up, because before we even get to the actual options there's a lil list of exceptions to the usual rules, and they matter:

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

• 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. 📚 order matters, always.
• The order of specifying the multiple -L options is significant. 👀
• Conforming applications shall specify each option separately — that is, grouping option letters (for example, -cg) need not be recognized by all implementations. so do NOT be out here combining your flags like it's a smoothie, some implementations will simply not get it.

---

and now the actual supported options, one by one, no skipping, periodt:

• -c — Suppress the link-edit phase of the compilation, and do not remove any object files that are produced. (compile only, no linking, keep the .os.)
• -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. 🐛🔍 debug girlies know.
• -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. (yes, asking for debug info and stripping it at the same time is chaos. the standard says "unspecified" and honestly, fair.)
• -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 unspecified. (ten of them minimum, so go off with your library paths.)
• -O optlevel — Specify the level of code optimization. Let's break it all the way down because it's a whole vibe:
  • 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. 🤫 (silence. blessed silence.)

Multiple instances of -L options can be specified. 🎀

---

💜 OPERANDS 💜

okay so an operand is either in the form of a pathname or the form -l library. And listen: at least one operand of the pathname form shall be specified. no pathnames, no party. 🚫

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. (so basically: don't bring random files to this function and expect a specific outcome.)

• -l library — (the letter ell, bestie, that's an L not a one 💅) Search the library named:

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.

---

🌈 STDIN 🌈

Not used. she doesn't read from stdin, she's not that kind of girlie. 💅

---

🍓 INPUT FILES 🍓

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 implementation-defined.

and here's a genuinely iconic little detail, don't miss it:

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

---

🧚 ENVIRONMENT VARIABLES 🧚

the following environment variables shall affect the execution of fort77:

• 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).
• LC_MESSAGES — 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. 🗂️

---

💫 ASYNCHRONOUS EVENTS 💫

Default. (no drama, no special handling, just default behavior. we love a low-maintenance moment.)

---

🌸 STDOUT 🌸

Not used. nothing to see here bestie, standard output is off duty. 💅

---

😭 STDERR 😭

The standard error shall be used only for diagnostic messages.

and here's the cute part: 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 value. (warnings ≠ errors, they're just little notes from the compiler, ok?)

---

🔥 OUTPUT FILES 🔥

Object files, listing files, and executable files shall be produced in unspecified formats. (formats? unspecified. mystery on purpose. we stan an enigmatic queen.)

---

👑 EXTENDED DESCRIPTION 👑

💖 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 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. (so like, the library might be a vibe and not a file. we simply accept this.)

🦋 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. (note that one: standard output, not standard error. yes really. 🙈)

---

💅 EXIT STATUS 💅

The following exit values shall be returned:

1. 0 — Successful compilation or link edit. ✅
2. >0 — An error occurred. ❌

---

🎀 CONSEQUENCES OF ERRORS 🎀

When fort77 encounters a compilation error, it shall:

• write a diagnostic to standard error, and
• continue to compile other source code operands. 💪 (she does not stop the whole party for one bad file, she keeps going, she's a professional.)

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 status. 🚪

The following sections are informative.

---

🌈 APPLICATION USAGE 🌈

None. nothing to add, bestie. it's giving minimalism. ✨

---

⭐ EXAMPLES ⭐

okay here's where it gets fun, let's actually run this thing:

Example 1 — compiles xyz.f and creates the executable file foo:

fort77 -o foo xyz.f

Example 2 — compiles xyz.f and creates the object file xyz.o:

fort77 -c xyz.f

Example 3 — compiles xyz.f and creates the executable file a.out:

fort77 xyz.f

Example 4 — compiles xyz.f, links it with b.o, and creates the executable a.out:

fort77 xyz.f b.o

see? not scary at all. you got this. 💖

💅 RATIONALE 💅

okay bestie, storytime ✨ so the name fort77? that was a choice. it was picked to parallel the renaming of the C compiler. and they specifically did not pick f77 because that would've caused drama with historical implementations. messy, we don't do that 💀

and the ANSI X3.9‐1978 standard got picked as the normative reference because the ISO/IEC version of FORTRAN-77 has been superseded by the ISO/IEC 1539:1991 standard. out with the old, i guess 🌸

---

so the file inclusion and symbol definition #define mechanisms that the c99 utility uses? yeah, those did not make it into this volume of POSIX.1‐2017 — even though they're commonly implemented — because there's literally no requirement that the FORTRAN compiler use the C preprocessor. it's giving "not our problem" 💁

and the -onetrip option? also not included in this volume of POSIX.1‐2017, even though many historical compilers support it. why? because it's derived from FORTRAN-66 and it's an anachronism that should not be perpetuated. it's giving grandma's flip phone, we're moving on 🙈

some implementations produce compilation listings. that whole aspect of FORTRAN got left unspecified because there was controversy over 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. two options, two collisions, zero consensus 😭

there's also 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. not now, maybe never, who's to say 💅

---

lowkey important one: 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. chaotic but that's the lore ✨

a reference to MIL-STD-1753 was removed from an early proposal in response to a request from the POSIX FORTRAN-binding standard developers. and 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. slay, redacted 🎀

---

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, bestie. 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. and fr fr, 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. periodt 💅

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. fair trade ✨

---

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. iykyk 🦋

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. trust the exit status, not the vibes 🔥

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. we're keeping it mysterious, main character energy 👑

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. read the synopsis, bestie, it's telling you something 🌈

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. parallel play but make it specs 💜

---

🔮 FUTURE DIRECTIONS 🔮

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. it's giving sunset era 🌅

---

👀 SEE ALSO 👀

• ar
• asa
• c99
• umask

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

go read those next, bestie, we stan a cross-reference 🫶

---

📜 COPYRIGHT 📜

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 http://www.opengroup.org/unix/online.html .

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 .

---

and that's a wrap on the whole page, bestie 💖 this came to you courtesy of IEEE / The Open Group, 2017, for FORT77(1P) — iconic, historic, and honestly a little chaotic, just how we like it. mwah 💅✨🎀