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
13 fort77 — FORTRAN compiler (FORTRAN)
14
16 fort77 [−c] [−g] [−L directory]... [−O optlevel] [−o outfile] [−s]
17 [−w] operand...
18
20 The fort77 utility is the interface to the FORTRAN compilation system;
21 it shall accept the full FORTRAN-77 language defined by the
22 ANSI X3.9‐1978 standard. The system conceptually consists of a compiler
23 and link editor. The files referenced by operands are compiled and
24 linked to produce an executable file. It is unspecified whether the
25 linking occurs entirely within the operation of fort77; some implemen‐
26 tations may produce objects that are not fully resolved until the file
27 is executed.
28 If the −c option is present, for all pathname operands of the form
30 file.f, the files:
31 $(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‐2008, 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‐2008, 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‐2008 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
132 A library is searched when its name is encountered, so the
134 placement of a −l operand is significant. Several standard
135 libraries can be specified in this manner, as described in
136 the EXTENDED DESCRIPTION section. Implementations may recog‐
137 nize implementation-defined suffixes other than .a as denot‐
138 ing libraries.
139
141 Not used.
142
144 The input file shall be one of the following: a text file containing
145 FORTRAN source code; an object file in the format produced by fort77
146 −c; or a library of object files, in the format produced by archiving
147 zero or more object files, using ar. Implementations may supply addi‐
148 tional utilities that produce files in these formats. Additional input
149 files are implementation-defined.
150 A <tab> encountered within the first six characters on a line of source
152 code shall cause the compiler to interpret the following character as
153 if it were the seventh character on the line (that is, in column 7).
154
156 The following environment variables shall affect the execution of
157 fort77:
158 LANG Provide a default value for the internationalization vari‐
160 ables that are unset or null. (See the Base Definitions vol‐
161 ume of POSIX.1‐2008, Section 8.2, Internationalization Vari‐
162 ables for the precedence of internationalization variables
163 used to determine the values of locale categories.)
164 LC_ALL If set to a non-empty string value, override the values of
166 all the other internationalization variables.
167 LC_CTYPE Determine the locale for the interpretation of sequences of
169 bytes of text data as characters (for example, single-byte as
170 opposed to multi-byte characters in arguments and input
171 files).
172 LC_MESSAGES
174 Determine the locale that should be used to affect the format
175 and contents of diagnostic messages written to standard
176 error.
177 NLSPATH Determine the location of message catalogs for the processing
179 of LC_MESSAGES.
180 TMPDIR Determine the pathname that should override the default
182 directory for temporary files, if any.
183
185 Default.
186
188 Not used.
189
191 The standard error shall be used only for diagnostic messages. If more
192 than one file operand ending in .f (or possibly other unspecified suf‐
193 fixes) is given, for each such file:
194 "%s:\n", <file>
196 may be written to allow identification of the diagnostic message with
198 the appropriate input file.
199 This utility may produce warning messages about certain conditions that
201 do not warrant returning an error (non-zero) exit value.
202
204 Object files, listing files, and executable files shall be produced in
205 unspecified formats.
206
208 Standard Libraries
209 The fort77 utility shall recognize the following −l operand for the
210 standard library:
211 −l f This library contains all functions referenced in the
213 ANSI X3.9‐1978 standard. This operand shall not be required
214 to be present to cause a search of this library.
215 In the absence of options that inhibit invocation of the link editor,
217 such as −c, the fort77 utility shall cause the equivalent of a −l f op‐
218 erand to be passed to the link editor as the last −l operand, causing
219 it to be searched after all other object files and libraries are
220 loaded.
221 It is unspecified whether the library libf.a exists as a regular file.
223 The implementation may accept as −l operands names of objects that do
224 not exist as regular files.
225 External Symbols
227 The FORTRAN compiler and link editor shall support the significance of
228 external symbols up to a length of at least 31 bytes; case folding is
229 permitted. The action taken upon encountering symbols exceeding the
230 implementation-defined maximum symbol length is unspecified.
231 The compiler and link editor shall support a minimum of 511 external
233 symbols per source or object file, and a minimum of 4095 external sym‐
234 bols total. A diagnostic message is written to standard output if the
235 implementation-defined limit is exceeded; other actions are unspeci‐
236 fied.
237
239 The following exit values shall be returned:
240 0 Successful compilation or link edit.
242 >0 An error occurred.
244
246 When fort77 encounters a compilation error, it shall write a diagnostic
247 to standard error and continue to compile other source code operands.
248 It shall return a non-zero exit status, but it is implementation-
249 defined whether an object module is created. If the link edit is unsuc‐
250 cessful, a diagnostic message shall be written to standard error, and
251 fort77 shall exit with a non-zero status.
252 The following sections are informative.
254
256 None.
257
259 The following usage example compiles xyz.f and creates the executable
260 file foo:
261 fort77 −o foo xyz.f
263 The following example compiles xyz.f and creates the object file xyz.o:
265 fort77 −c xyz.f
267 The following example compiles xyz.f and creates the executable file
269 a.out:
270 fort77 xyz.f
272 The following example compiles xyz.f, links it with b.o, and creates
274 the executable a.out:
275 fort77 xyz.f b.o
277
279 The name of this utility was chosen as fort77 to parallel the renaming
280 of the C compiler. The name f77 was not chosen to avoid problems with
281 historical implementations. The ANSI X3.9‐1978 standard was selected as
282 a normative reference because the ISO/IEC version of FORTRAN-77 has
283 been superseded by the ISO/IEC 1539:1991 standard.
284 The file inclusion and symbol definition #define mechanisms used by the
286 c99 utility were not included in this volume of POSIX.1‐2008—even
287 though they are commonly implemented—since there is no requirement that
288 the FORTRAN compiler use the C preprocessor.
289 The −onetrip option was not included in this volume of POSIX.1‐2008,
291 even though many historical compilers support it, because it is derived
292 from FORTRAN-66; it is an anachronism that should not be perpetuated.
293 Some implementations produce compilation listings. This aspect of FOR‐
295 TRAN has been left unspecified because there was controversy concerning
296 the various methods proposed for implementing it: a −V option over‐
297 lapped with historical vendor practice and a naming convention of cre‐
298 ating files with .l suffixes collided with historical lex file naming
299 practice.
300 There is no −I option in this version of this volume of POSIX.1‐2008 to
302 specify a directory for file inclusion. An INCLUDE directive has been a
303 part of the Fortran-90 discussions, but an interface supporting that
304 standard is not in the current scope.
305 It is noted that many FORTRAN compilers produce an object module even
307 when compilation errors occur; during a subsequent compilation, the
308 compiler may patch the object module rather than recompiling all the
309 code. Consequently, it is left to the implementor whether or not an
310 object file is created.
311 A reference to MIL-STD-1753 was removed from an early proposal in
313 response to a request from the POSIX FORTRAN-binding standard develop‐
314 ers. It was not the intention of the standard developers to require
315 certification of the FORTRAN compiler, and IEEE Std 1003.9‐1992 does
316 not specify the military standard or any special preprocessing require‐
317 ments. Furthermore, use of that document would have been inappropriate
318 for an international standard.
319 The specification of optimization has been subject to changes through
321 early proposals. At one time, −O and −N were Booleans: optimize and do
322 not optimize (with an unspecified default). Some historical practice
323 led this to be changed to:
324 −O 0 No optimization.
326 −O 1 Some level of optimization.
328 −O n Other, unspecified levels of optimization.
330 It is not always clear whether ``good code generation'' is the same
332 thing as optimization. Simple optimizations of local actions do not
333 usually affect the semantics of a program. The −O 0 option has been
334 included to accommodate the very particular nature of scientific calcu‐
335 lations in a highly optimized environment; compilers make errors. Some
336 degree of optimization is expected, even if it is not documented here,
337 and the ability to shut it off completely could be important when port‐
338 ing an application. An implementation may treat −O 0 as ``do less than
339 normal'' if it wishes, but this is only meaningful if any of the opera‐
340 tions it performs can affect the semantics of a program. It is highly
341 dependent on the implementation whether doing less than normal is logi‐
342 cal. It is not the intent of the −O 0 option to ask for inefficient
343 code generation, but rather to assure that any semantically visible
344 optimization is suppressed.
345 The specification of standard library access is consistent with the C
347 compiler specification. Implementations are not required to have
348 /usr/lib/libf.a, as many historical implementations do, but if not they
349 are required to recognize f as a token.
350 External symbol size limits are in normative text; conforming applica‐
352 tions need to know these limits. However, the minimum maximum symbol
353 length should be taken as a constraint on a conforming application, not
354 on an implementation, and consequently the action taken for a symbol
355 exceeding the limit is unspecified. The minimum size for the external
356 symbol table was added for similar reasons.
357 The CONSEQUENCES OF ERRORS section clearly specifies the behavior of
359 the compiler when compilation or link-edit errors occur. The behavior
360 of several historical implementations was examined, and the choice was
361 made to be silent on the status of the executable, or a.out, file in
362 the face of compiler or linker errors. If a linker writes the exe‐
363 cutable file, then links it on disk with lseek()s and write()s, the
364 partially linked executable file can be left on disk and its execute
365 bits turned off if the link edit fails. However, if the linker links
366 the image in memory before writing the file to disk, it need not touch
367 the executable file (if it already exists) because the link edit fails.
368 Since both approaches are historical practice, a conforming application
369 shall rely on the exit status of fort77, rather than on the existence
370 or mode of the executable file.
371 The −g and −s options are not specified as mutually-exclusive. Histori‐
373 cally, these two options have been mutually-exclusive, but because both
374 are so loosely specified, it seemed appropriate to leave their interac‐
375 tion unspecified.
376 The requirement that conforming applications specify compiler options
378 separately is to reserve the multi-character option name space for ven‐
379 dor-specific compiler options, which are known to exist in many histor‐
380 ical implementations. Implementations are not required to recognize,
381 for example, −gc as if it were −g −c; nor are they forbidden from doing
382 so. The SYNOPSIS shows all of the options separately to highlight this
383 requirement on applications.
384 Echoing filenames to standard error is considered a diagnostic message
386 because it would otherwise be difficult to associate an error message
387 with the erring file. They are described with ``may'' to allow imple‐
388 mentations to use other methods of identifying files and to parallel
389 the description in c99.
390
392 A compilation system based on the ISO/IEC 1539:1991 standard may be
393 considered for a future version; it may have a different utility name
394 from fort77.
395
397 ar, asa, c99, umask
398 The Base Definitions volume of POSIX.1‐2008, Chapter 8, Environment
400 Variables, Section 12.2, Utility Syntax Guidelines
401 The System Interfaces volume of POSIX.1‐2008, exec
403
405 Portions of this text are reprinted and reproduced in electronic form
406 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
407 -- Portable Operating System Interface (POSIX), The Open Group Base
408 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
409 cal and Electronics Engineers, Inc and The Open Group. (This is
410 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
411 event of any discrepancy between this version and the original IEEE and
412 The Open Group Standard, the original IEEE and The Open Group Standard
413 is the referee document. The original Standard can be obtained online
414 at http://www.unix.org/online.html .
415 Any typographical or formatting errors that appear in this page are
417 most likely to have been introduced during the conversion of the source
418 files to man page format. To report such errors, see https://www.ker‐
419 nel.org/doc/man-pages/reporting_bugs.html .
420IEEE/The Open Group 2013 FORT77(1P)