This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
A couple of FORTRAN porting questions for g77
- From: "Howard Chiger, hchiger at ttinet dot com" <hchiger at ttinet dot com>
- To: gcc at gcc dot gnu dot org
- Cc: hchiger at ttinet dot com
- Date: Fri, 7 Jun 2002 08:50:18 -1300
- Subject: A couple of FORTRAN porting questions for g77
Hi.
Or maybe that should be Help!
I am a mechanical engineer who has been using some NASA analysis programs,
written in FORTRAN, for the past 30 years. During that time, I have ported
them from their original UNIVAC to IBM to VAX/VMS to AlphaVMS to Digital
Unix. Each time I was sure that NOW they were completely portable and should
I ever have to move them again, it would be a breeze. Hah!
I have recently loaded Linux on a PC (which is 3x faster than my Alpha
Workstation) and if I can get my programs to work, then maybe I can too.
Yet I have been hitting some really fundamental snags. I have read
screenfulls of man and info g77 pages, and bugged everyone I know, all to
no avail. I am concluding that I may be the last man in America with
FORTRAN programs. (And these are basically FORTRAN II and IV, not even
F77, so we aren't talking fancy.)
So, although I hate to bother you, this is my last gasp at getting these
codes to work. So please, would you take a few minutes and try to point
me in the correct direction?
I have 3 basic problems.
1) My codes do a lot of file I/O. (They were written when 1 Mb of memory
was huge, so they store a lot on disk). They write files to disk using
external unit assignments. For example, on a VAX, I assign a unit number to a
file:
$ ASSIGN file_name FOR016
then, a FORTRAN WRITE(16,xxx) will write to the path defined as file_name.
On my Digital Unix (csh) port, the command would be
setenv FORT16 file_name
But for the life of me, I can't find the assignment that works for g77.
I have setenv'ed to fort16, fort016, fort.16, for16, for016, and also
FORT16, FORT016, FORT.16, FOR16, FOR016. All unsuccessfully. I can
only generate file output to fort.16. Can you tell me the secret password????
2) I use many PARAMETER statements and always use an IMPLICIT NONE, e.g.,
IMPLICIT NONE
PARAMETER NDIM=100
g77 requires the PARAMETER be typed implicitly:
PARAMETER (NDIM=100)
and doesn't seem to allow it to be typed. Thus I have had to remove the
IMPLICIT NONE in each routine to get it to compile. This is an acceptable
workaround, especially since the codes are pretty static in their
development. But I feel naked without my IMPLICIT NONE statement.
Is there a different workaround?
3) I also need to be able to feed the program input command line
parameters. (This may be doable with some non standard intrinsic functions
I noted during my info readings, GETARG and IARGC. I haven't looked into this
yet, but the names indicate this. VMS has a similar system intrinsic,
LIB$GET_FOREIGN). But I want to stay away from non standard things. So
I have created a C main program that simply gets argc number of argv
parameters and passes them to my FORTRAN program, which now "starts" with a
subroutine rather than a main.
I had expected problems passing the strings from C to FORTRAN. On my
DEC/COMPAQ machines, FORTRAN strings are passed as descriptors, not
null terminated strings, and there is a system header, <descrip.h>
to facilitate this. This GNU header doesn't exist, I am not surprised, but
I can find no mention of how to do this. Can you tell me?
In any event, that isn't even my immediate problem. I wanted to simply
test compiling and linking a multilanguage program and couldn't!
I have main.c and sub.f.
I tried:
$ g77 main.c sub.f
and
$ gcc -c main.c
$ g77 main.o sub.f
And both gave me
main.o(.text+0x38): undefined reference to `sub'
How can I do this? And how can I set up a make file to implement this
multi complile/link?
Again, let me apologize for contacting you directly, but I can't think
of anyone else at this point. I would greatly appreciate any help
you can give me. And though I basically do all my work in C now,
I still think of FORTRAN as my first language and don't want to see
it relegated to relic or obsolete status. If there is anything I
can do to help you, be it code development or testing, please do not
hesitate to ask me.
Thanks again,
Howard Chiger
San Diego, CA
hchiger@ttinet.com