1FORT77(1P) POSIX Programmer's Manual FORT77(1P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 fort77 — FORTRAN compiler (FORTRAN)
13
15 fort77 [-c] [-g] [-L directory]... [-O optlevel] [-o outfile] [-s]
16 [-w] operand...
17
19 The fort77 utility is the interface to the FORTRAN compilation system;
20 it shall accept the full FORTRAN-77 language defined by the
21 ANSI X3.9‐1978 standard. The system conceptually consists of a compiler
22 and link editor. The files referenced by operands are compiled and
23 linked to produce an executable file. It is unspecified whether the
24 linking occurs entirely within the operation of fort77; some implemen‐
25 tations may produce objects that are not fully resolved until the file
26 is executed.
27 If the -c option is present, for all pathname operands of the form
29 file.f, the files:
30 $(basename pathname.f).o
33 shall be created or overwritten as the result of successful compila‐
35 tion. If the -c option is not specified, it is unspecified whether such
36 .o files are created or deleted for the file.f operands.
37 If there are no options that prevent link editing (such as -c) and all
39 operands compile and link without error, the resulting executable file
40 shall be written into the file named by the -o option (if present) or
41 to the file a.out. The executable file shall be created as specified
42 in the System Interfaces volume of POSIX.1‐2017, except that the file
43 permissions shall be set to: S_IRWXO | S_IRWXG | S_IRWXU
44 and that the bits specified by the umask of the process shall be
46 cleared.
47
49 The fort77 utility shall conform to the Base Definitions volume of
50 POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines, except that:
51 * The -l library operands have the format of options, but their posi‐
53 tion within a list of operands affects the order in which libraries
54 are searched.
55 * The order of specifying the multiple -L options is significant.
57 * Conforming applications shall specify each option separately; that
59 is, grouping option letters (for example, -cg) need not be recog‐
60 nized by all implementations.
61 The following options shall be supported:
63 -c Suppress the link-edit phase of the compilation, and do not
65 remove any object files that are produced.
66 -g Produce symbolic information in the object or executable
68 files; the nature of this information is unspecified, and may
69 be modified by implementation-defined interactions with other
70 options.
71 -s Produce object or executable files, or both, from which sym‐
73 bolic and other information not required for proper execution
74 using the exec family of functions defined in the System
75 Interfaces volume of POSIX.1‐2017 has been removed
76 (stripped). If both -g and -s options are present, the
77 action taken is unspecified.
78 -o outfile
80 Use the pathname outfile, instead of the default a.out, for
81 the executable file produced. If the -o option is present
82 with -c, the result is unspecified.
83 -L directory
85 Change the algorithm of searching for the libraries named in
86 -l operands to look in the directory named by the directory
87 pathname before looking in the usual places. Directories
88 named in -L options shall be searched in the specified order.
89 At least ten instances of this option shall be supported in a
90 single fort77 command invocation. If a directory specified by
91 a -L option contains a file named libf.a, the results are
92 unspecified.
93 -O optlevel
95 Specify the level of code optimization. If the optlevel
96 option-argument is the digit '0', all special code optimiza‐
97 tions shall be disabled. If it is the digit '1', the nature
98 of the optimization is unspecified. If the -O option is omit‐
99 ted, the nature of the system's default optimization is
100 unspecified. It is unspecified whether code generated in the
101 presence of the -O 0 option is the same as that generated
102 when -O is omitted. Other optlevel values may be supported.
103 -w Suppress warnings.
105 Multiple instances of -L options can be specified.
107
109 An operand is either in the form of a pathname or the form -l library.
110 At least one operand of the pathname form shall be specified. The fol‐
111 lowing operands shall be supported:
112 file.f The pathname of a FORTRAN source file to be compiled and
114 optionally passed to the link editor. The filename operand
115 shall be of this form if the -c option is used.
116 file.a A library of object files typically produced by ar, and
118 passed directly to the link editor. Implementations may rec‐
119 ognize implementation-defined suffixes other than .a as
120 denoting object file libraries.
121 file.o An object file produced by fort77 -c and passed directly to
123 the link editor. Implementations may recognize implementa‐
124 tion-defined suffixes other than .o as denoting object files.
125 The processing of other files is implementation-defined.
127 -l library
129 (The letter ell.) Search the library named:
130 liblibrary.a
133 A library is searched when its name is encountered, so the
135 placement of a -l operand is significant. Several standard
136 libraries can be specified in this manner, as described in
137 the EXTENDED DESCRIPTION section. Implementations may recog‐
138 nize implementation-defined suffixes other than .a as denot‐
139 ing libraries.
140
142 Not used.
143
145 The input file shall be one of the following: a text file containing
146 FORTRAN source code; an object file in the format produced by fort77
147 -c; or a library of object files, in the format produced by archiving
148 zero or more object files, using ar. Implementations may supply addi‐
149 tional utilities that produce files in these formats. Additional input
150 files are implementation-defined.
151 A <tab> encountered within the first six characters on a line of source
153 code shall cause the compiler to interpret the following character as
154 if it were the seventh character on the line (that is, in column 7).
155
157 The following environment variables shall affect the execution of
158 fort77:
159 LANG Provide a default value for the internationalization vari‐
161 ables that are unset or null. (See the Base Definitions vol‐
162 ume of POSIX.1‐2017, Section 8.2, Internationalization Vari‐
163 ables for the precedence of internationalization variables
164 used to determine the values of locale categories.)
165 LC_ALL If set to a non-empty string value, override the values of
167 all the other internationalization variables.
168 LC_CTYPE Determine the locale for the interpretation of sequences of
170 bytes of text data as characters (for example, single-byte as
171 opposed to multi-byte characters in arguments and input
172 files).
173 LC_MESSAGES
175 Determine the locale that should be used to affect the format
176 and contents of diagnostic messages written to standard
177 error.
178 NLSPATH Determine the location of message catalogs for the processing
180 of LC_MESSAGES.
181 TMPDIR Determine the pathname that should override the default
183 directory for temporary files, if any.
184
186 Default.
187
189 Not used.
190
192 The standard error shall be used only for diagnostic messages. If more
193 than one file operand ending in .f (or possibly other unspecified suf‐
194 fixes) is given, for each such file:
195 "%s:\n", <file>
198 may be written to allow identification of the diagnostic message with
200 the appropriate input file.
201 This utility may produce warning messages about certain conditions that
203 do not warrant returning an error (non-zero) exit value.
204
206 Object files, listing files, and executable files shall be produced in
207 unspecified formats.
208
210 Standard Libraries
211 The fort77 utility shall recognize the following -l operand for the
212 standard library:
213 -l f This library contains all functions referenced in the
215 ANSI X3.9‐1978 standard. This operand shall not be required
216 to be present to cause a search of this library.
217 In the absence of options that inhibit invocation of the link editor,
219 such as -c, the fort77 utility shall cause the equivalent of a -l f op‐
220 erand to be passed to the link editor as the last -l operand, causing
221 it to be searched after all other object files and libraries are
222 loaded.
223 It is unspecified whether the library libf.a exists as a regular file.
225 The implementation may accept as -l operands names of objects that do
226 not exist as regular files.
227 External Symbols
229 The FORTRAN compiler and link editor shall support the significance of
230 external symbols up to a length of at least 31 bytes; case folding is
231 permitted. The action taken upon encountering symbols exceeding the
232 implementation-defined maximum symbol length is unspecified.
233 The compiler and link editor shall support a minimum of 511 external
235 symbols per source or object file, and a minimum of 4095 external sym‐
236 bols total. A diagnostic message is written to standard output if the
237 implementation-defined limit is exceeded; other actions are unspeci‐
238 fied.
239
241 The following exit values shall be returned:
242 0 Successful compilation or link edit.
244 >0 An error occurred.
246
248 When fort77 encounters a compilation error, it shall write a diagnostic
249 to standard error and continue to compile other source code operands.
250 It shall return a non-zero exit status, but it is implementation-
251 defined whether an object module is created. If the link edit is unsuc‐
252 cessful, a diagnostic message shall be written to standard error, and
253 fort77 shall exit with a non-zero status.
254 The following sections are informative.
256
258 None.
259
261 The following usage example compiles xyz.f and creates the executable
262 file foo:
263 fort77 -o foo xyz.f
266 The following example compiles xyz.f and creates the object file xyz.o:
268 fort77 -c xyz.f
271 The following example compiles xyz.f and creates the executable file
273 a.out:
274 fort77 xyz.f
277 The following example compiles xyz.f, links it with b.o, and creates
279 the executable a.out:
280 fort77 xyz.f b.o
283
285 The name of this utility was chosen as fort77 to parallel the renaming
286 of the C compiler. The name f77 was not chosen to avoid problems with
287 historical implementations. The ANSI X3.9‐1978 standard was selected as
288 a normative reference because the ISO/IEC version of FORTRAN-77 has
289 been superseded by the ISO/IEC 1539:1991 standard.
290 The file inclusion and symbol definition #define mechanisms used by the
292 c99 utility were not included in this volume of POSIX.1‐2017—even
293 though they are commonly implemented—since there is no requirement that
294 the FORTRAN compiler use the C preprocessor.
295 The -onetrip option was not included in this volume of POSIX.1‐2017,
297 even though many historical compilers support it, because it is derived
298 from FORTRAN-66; it is an anachronism that should not be perpetuated.
299 Some implementations produce compilation listings. This aspect of FOR‐
301 TRAN has been left unspecified because there was controversy concerning
302 the various methods proposed for implementing it: a -V option over‐
303 lapped with historical vendor practice and a naming convention of cre‐
304 ating files with .l suffixes collided with historical lex file naming
305 practice.
306 There is no -I option in this version of this volume of POSIX.1‐2017 to
308 specify a directory for file inclusion. An INCLUDE directive has been a
309 part of the Fortran-90 discussions, but an interface supporting that
310 standard is not in the current scope.
311 It is noted that many FORTRAN compilers produce an object module even
313 when compilation errors occur; during a subsequent compilation, the
314 compiler may patch the object module rather than recompiling all the
315 code. Consequently, it is left to the implementor whether or not an
316 object file is created.
317 A reference to MIL-STD-1753 was removed from an early proposal in
319 response to a request from the POSIX FORTRAN-binding standard develop‐
320 ers. It was not the intention of the standard developers to require
321 certification of the FORTRAN compiler, and IEEE Std 1003.9‐1992 does
322 not specify the military standard or any special preprocessing require‐
323 ments. Furthermore, use of that document would have been inappropriate
324 for an international standard.
325 The specification of optimization has been subject to changes through
327 early proposals. At one time, -O and -N were Booleans: optimize and do
328 not optimize (with an unspecified default). Some historical practice
329 led this to be changed to:
330 -O 0 No optimization.
332 -O 1 Some level of optimization.
334 -O n Other, unspecified levels of optimization.
336 It is not always clear whether ``good code generation'' is the same
338 thing as optimization. Simple optimizations of local actions do not
339 usually affect the semantics of a program. The -O 0 option has been
340 included to accommodate the very particular nature of scientific calcu‐
341 lations in a highly optimized environment; compilers make errors. Some
342 degree of optimization is expected, even if it is not documented here,
343 and the ability to shut it off completely could be important when port‐
344 ing an application. An implementation may treat -O 0 as ``do less than
345 normal'' if it wishes, but this is only meaningful if any of the opera‐
346 tions it performs can affect the semantics of a program. It is highly
347 dependent on the implementation whether doing less than normal is logi‐
348 cal. It is not the intent of the -O 0 option to ask for inefficient
349 code generation, but rather to assure that any semantically visible
350 optimization is suppressed.
351 The specification of standard library access is consistent with the C
353 compiler specification. Implementations are not required to have
354 /usr/lib/libf.a, as many historical implementations do, but if not they
355 are required to recognize f as a token.
356 External symbol size limits are in normative text; conforming applica‐
358 tions need to know these limits. However, the minimum maximum symbol
359 length should be taken as a constraint on a conforming application, not
360 on an implementation, and consequently the action taken for a symbol
361 exceeding the limit is unspecified. The minimum size for the external
362 symbol table was added for similar reasons.
363 The CONSEQUENCES OF ERRORS section clearly specifies the behavior of
365 the compiler when compilation or link-edit errors occur. The behavior
366 of several historical implementations was examined, and the choice was
367 made to be silent on the status of the executable, or a.out, file in
368 the face of compiler or linker errors. If a linker writes the exe‐
369 cutable file, then links it on disk with lseek()s and write()s, the
370 partially linked executable file can be left on disk and its execute
371 bits turned off if the link edit fails. However, if the linker links
372 the image in memory before writing the file to disk, it need not touch
373 the executable file (if it already exists) because the link edit fails.
374 Since both approaches are historical practice, a conforming application
375 shall rely on the exit status of fort77, rather than on the existence
376 or mode of the executable file.
377 The -g and -s options are not specified as mutually-exclusive. Histori‐
379 cally, these two options have been mutually-exclusive, but because both
380 are so loosely specified, it seemed appropriate to leave their interac‐
381 tion unspecified.
382 The requirement that conforming applications specify compiler options
384 separately is to reserve the multi-character option name space for ven‐
385 dor-specific compiler options, which are known to exist in many histor‐
386 ical implementations. Implementations are not required to recognize,
387 for example, -gc as if it were -g -c; nor are they forbidden from doing
388 so. The SYNOPSIS shows all of the options separately to highlight this
389 requirement on applications.
390 Echoing filenames to standard error is considered a diagnostic message
392 because it would otherwise be difficult to associate an error message
393 with the erring file. They are described with ``may'' to allow imple‐
394 mentations to use other methods of identifying files and to parallel
395 the description in c99.
396
398 Future versions of this standard may withdraw this utility. There are
399 implementations of compilers that conform to much more recent versions
400 of the FORTRAN programming language. Since there is no active FORTRAN
401 binding to POSIX.1‐2008, this standard does not need to specify any
402 compiler.
403
405 ar, asa, c99, umask
406 The Base Definitions volume of POSIX.1‐2017, Chapter 8, Environment
408 Variables, Section 12.2, Utility Syntax Guidelines
409 The System Interfaces volume of POSIX.1‐2017, exec
411
413 Portions of this text are reprinted and reproduced in electronic form
414 from IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
415 table Operating System Interface (POSIX), The Open Group Base Specifi‐
416 cations Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of
417 Electrical and Electronics Engineers, Inc and The Open Group. In the
418 event of any discrepancy between this version and the original IEEE and
419 The Open Group Standard, the original IEEE and The Open Group Standard
420 is the referee document. The original Standard can be obtained online
421 at http://www.opengroup.org/unix/online.html .
422 Any typographical or formatting errors that appear in this page are
424 most likely to have been introduced during the conversion of the source
425 files to man page format. To report such errors, see https://www.ker‐
426 nel.org/doc/man-pages/reporting_bugs.html .
427IEEE/The Open Group 2017 FORT77(1P)