g77 compiling HP-UX 6.5B Fortran files
Matt
I'm trying to compile some very old software on a modern Linux system
with gFortran. This is an effort to reduce compile times but I'm
running into several issues. First off I'm using a Syslib.h (Fortran)
file that has $ALIAS commands in it so that the Fortran code I'm
compiling can share variables with some C code. The g77 compiler
gives the following error when trying to include the $ALIAS commands:
Syslib.h:85:
$ALIAS Trace_flag = 'Trace_flag'
^
Invalid first character at (^) [info -f g77 M LEX]
The line starts at column 0 which is the way it is on the HP-UX system
that can successfully compile this software package. A second problem
I am encountering is with some directives that are used by the HP-UX
Fortran compiler. These are directives such as $TITLE and $OPTIONS
LIST. Here is a sample:
$TITLE 'Call Hello'
$OPTIONS LIST OFF
$INCLUDE 'Syslib.h'
$OPTIONS LIST ON
If I remove the $TITLE and $OPTIONS lines, remove the $ from $INCLUDE,
and move the INCLUDE statement to the 7th column the compiler will try
to include the header file and produce the afore mentioned Invalid
character error.
I am attempting these compiles with the following command line:
f77 -fdollar-ok -fbackslash -I. -fno-automatic Hello.F
I am intentionally using the capitol F in the extension for
preprocessing but I am not 100% sure this is necessary. I strongly
believe the issues I'm encountering are due to the differences in the
way the HP-UX 6.5B Fortran compiler works verses the g77 compiler but
if it is at all possible to make this work without changing the source
it would help me out tremendously.
Has anyone tried to revive or compile code of a similar age /
configuration? If so, how did you get the modern compiler to either
work with these directives or ignore them? If the source needs to be
changed, could anyone point me in the right direction as to what I
need to change? I've tried several configurations of the $ALIAS
statement with no luck as well as rearranging and even deleting the
directives with limited success.
Please help!
Matt
Tobias Burnus
Matt wrote:
> I'm trying to compile some very old software on a modern Linux system
> with gFortran. [...] The g77 compiler
>
First, g77 and gfortran are two different Fortran compilers, which both
were/are shipping with the GNU Compiler Collection (GCC).
"g77" was part of GCC up to 3.4.x and was replaces by "gfortran" in GCC 4.x.
As the name indicates, "g77" is a FORTRAN 77 compiler (with vendor
extensions). While (as the name does not indicate) gfortran is a Fortran
95 compiler with Fortran 2003 features and vendor extensions. "gfortran"
should be able to compile all Fortran 77 programs and almost all
programs which compile with g77. If you have a modern Linux, you should
have also the "gfortran" compiler available. (Please use at least
gfortran version 4.1.x.)
It seems that gfortran supports more legacy Fortran programs than g77
and has better diagnostics thus I would recommend to use "gfortran" and
not "g77" (alias "f77").
> $ALIAS Trace_flag = 'Trace_flag'
> ^
> Invalid first character at (^) [info -f g77 M LEX]
>
$ALIAS is an extension of HP's Fortran compiler, which is not supported
by gfortran. (In the old days, Fortran compiler vendors added lots of
extensions, many of which are only supported by few compilers). The
$ALIAS syntax is explained at:
http://docs.hp.com/cgi-bin/doc3k/B3150190021.12118/125
It is not trivial to support this. "$ALIAS Trace_flag = 'Trace_flag'"
means that the procedure is called "Trace_flag" and not "trace_flag_".
(Fortran's procedure names are case insensitive while C's names are case
sensitive; I assume "Trace_flag" is written in C.)
There are two solutions, which are both not really trivial. First,
comment the ALIAS directive. Secondly and nontrivial:
a) If you have the source code of the function "Trace_flag" (probably
written in C), you can rename it to "trace_flag_".
b) You can create an explicit interface for it
interface
subroutine trace_flag( ... ) bind(c, name="Trace_flag")
...
end interface
Without knowing more about the program I cannot tell you how the "..."
should look like or whether "subroutine" is supposed to be a "function".
> $TITLE 'Call Hello'
>
http://docs.hp.com/cgi-bin/doc3k/B3150190021.12118/177
> $OPTIONS LIST OFF
>
I could not find any definition for "$OPTIONS", only for "$LIST":
http://docs.hp.com/cgi-bin/doc3k/B3150190021.12118/148
> f77 -fdollar-ok -fbackslash -I. -fno-automatic Hello.F
>
-fdollar is wrong for "$ALIAS" etc. It allows variable names to contain
$ signs, however, $ALIAS is not a variable name but a directive.
> I am intentionally using the capitol F in the extension for
> preprocessing but I am not 100% sure this is necessary.
The captial .F causes the compiler to run the source code through the C
preprocessor (cpp). I'm not sure whether this is needed or not, I'd
guess it is not, but usually it does not harm either.
> I strongly
> believe the issues I'm encountering are due to the differences in the
> way the HP-UX 6.5B Fortran compiler works verses the g77 compiler but
> if it is at all possible to make this work without changing the source
> it would help me out tremendously.
>
Indeed this is the problem, however, it is not trivial to get the
program running without some nontrivial modifications with gfortran.
Unless I missed something, also Intel's ifort compiler (which supports
the $DEC extensions) or Sun's sunf95 do not support this extension.
(This is really the disadvantage of old code: It uses tons of vendor
extensions and is tailored for a specific compiler. With all other
compilers it does not work or - even worse - it compiles and creates
wrong output because of some assumptions which were true [e.g. by
chance] for one compiler. Nowadays, all compiler vendors strive to
support the Fortran standard completely and discourage to use vendor
extensions. And also most developers try to stick to standard Fortran.
Unfortunately, this does not help for old programs.)
> Has anyone tried to revive or compile code of a similar age /
> configuration?
>
Yes and no. I had code of similar age (I'd guess), but it did not use HP
vendor directives.
I believe that gfortran will never support the HP directives, but I
might be wrong. At least it is not planed to implement them for the
foreseeable future (though patches might get accepted).
Current main goals are (a) to fix bugs and (b) to support Fortran 2003
features (and then Fortran 2008). Some directive support (esp. for
32bit-Windows' STDCALL) is planned, however, this is still at an early
stage and while it might help for your program, it still won't run out
of the box.
Tobias