fort77 man page on Archlinux

Man page or keyword search:  
man Server   11224 pages
apropos Keyword Search (all sections)
Output format
Archlinux logo
[printable version]

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

       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.

       fort77 — FORTRAN compiler (FORTRAN)

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

       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 implemen‐
       tations 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  compila‐
       tion. 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‐2008, 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

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

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

	*  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	recog‐
	   nized 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

       −s	 Produce  object or executable files, or both, from which sym‐
		 bolic and other information not required for proper execution
		 using	the  exec  family  of  functions defined in the System
		 Interfaces  volume   of   POSIX.1‐2008	  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  optimiza‐
		 tions	shall  be disabled. If it is the digit '1', the nature
		 of the optimization is unspecified. If the −O option is omit‐
		 ted,  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.

       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 fol‐
       lowing 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 rec‐
		 ognize	 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  implementa‐
		 tion-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 recog‐
		 nize  implementation-defined suffixes other than .a as denot‐
		 ing libraries.

       Not used.

       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 addi‐
       tional utilities that produce files in these formats. Additional	 input
       files are implementation-defined.

       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	 vari‐
		 ables	that are unset or null. (See the Base Definitions vol‐
		 ume of POSIX.1‐2008, Section 8.2, Internationalization	 Vari‐
		 ables	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

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

       NLSPATH	 Determine the location of message catalogs for the processing

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


       Not used.

       The standard error shall be used only for diagnostic messages.  If more
       than  one file operand ending in .f (or possibly other unspecified suf‐
       fixes) 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.

       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 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 op‐
       erand 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

       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  sym‐
       bols  total.  A diagnostic message is written to standard output if the
       implementation-defined limit is exceeded; other	actions	 are  unspeci‐

       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 unsuc‐
       cessful,	 a  diagnostic message shall be written to standard error, and
       fort77 shall exit with a non-zero status.

       The following sections are informative.


       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 xyz.o:

	   fort77 −c xyz.f

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

	   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  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‐2008—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‐2008,
       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  FOR‐
       TRAN has been left unspecified because there was controversy concerning
       the various methods proposed for implementing it:  a  −V	 option	 over‐
       lapped  with historical vendor practice and a naming convention of cre‐
       ating files with .l suffixes collided with historical lex  file	naming

       There is no −I option in this version of this volume of POSIX.1‐2008 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 develop‐
       ers. 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 require‐
       ments.  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:

       −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 calcu‐
       lations	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 port‐
       ing 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 opera‐
       tions it performs can affect the semantics of a program. It  is	highly
       dependent on the implementation whether doing less than normal is logi‐
       cal. 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 applica‐
       tions 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  exe‐
       cutable	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. Histori‐
       cally, these two options have been mutually-exclusive, but because both
       are so loosely specified, it seemed appropriate to leave their interac‐
       tion unspecified.

       The  requirement	 that conforming applications specify compiler options
       separately is to reserve the multi-character option name space for ven‐
       dor-specific compiler options, which are known to exist in many histor‐
       ical 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 imple‐
       mentations to use other methods of identifying files  and  to  parallel
       the description in c99.

       A  compilation  system  based  on the ISO/IEC 1539:1991 standard may be
       considered for a future version; it may have a different	 utility  name
       from fort77.

       ar, asa, c99, umask

       The  Base  Definitions  volume  of POSIX.1‐2008, Chapter 8, Environment
       Variables, Section 12.2, Utility Syntax Guidelines

       The System Interfaces volume of POSIX.1‐2008, exec

       Portions of this text are reprinted and reproduced in  electronic  form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX),	The  Open  Group  Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
       cal and Electronics Engineers,  Inc  and	 The  Open  Group.   (This  is
       POSIX.1-2008  with  the	2013  Technical Corrigendum 1 applied.) 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 https://www.ker‐ .

IEEE/The Open Group		     2013			    FORT77(1P)

List of man pages available for Archlinux

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net