Compile antiquated fortran?
I have old fortran source code (not my own work) for a specialized statistical program that I and others find quite useful. A few years ago I was able to compile it on Linux using gfortran with std=legacy (and also cross-compile it for Windows an Mac). Now I'd like to rebuild it, but with recent gfortran (I've tried 12.2.1 on Fedora and 13.1.1 on Arch) it's a no-go. I get lots of errors of the following sort: ansub9.f:151:44: 151 |INTEGER ITYPE,INIT,LAM,IMEAN,IP,ID,Q,BP,BD,BQ,SQG,MQ,L,M, | 1 Error: Symbol ‘q’ at (1) already has basic type of REAL I can understand this complaint. The code contains this sort of thing within a given subroutine: IMPLICIT REAL*8 (A-H,O-Z) then some lines later on: INTEGER ITYPE,INIT,LAM,IMEAN,P,D,Q,... I guess the author was assuming that an explicit type-assignment just overrides an implicit one. Older gfortran apparently played along with that. My question: Given that I'm already using -std=legacy, are there any other flags that I could add to get the code to compile? (I know I could tackle this by renaming a bunch of variables, but in context that would be an extremely fiddly job.) Thanks for any help. -- Allin Cottrell Department of Economics Wake Forest University
Re: Compile antiquated fortran?
On Thu, 27 Jul 2023, Jerry D wrote: On 7/27/23 1:36 PM, Allin Cottrell via Fortran wrote: I have old fortran source code (not my own work) for a specialized statistical program that I and others find quite useful. A few years ago I was able to compile it on Linux using gfortran with std=legacy (and also cross-compile it for Windows an Mac). Now I'd like to rebuild it, but with recent gfortran (I've tried 12.2.1 on Fedora and 13.1.1 on Arch) it's a no-go. I get lots of errors of the following sort: ansub9.f:151:44: 151 | INTEGER ITYPE,INIT,LAM,IMEAN,IP,ID,Q,BP,BD,BQ,SQG,MQ,L,M, | 1 Error: Symbol ‘q’ at (1) already has basic type of REAL I can understand this complaint. The code contains this sort of thing within a given subroutine: IMPLICIT REAL*8 (A-H,O-Z) Have you considered replacing the above line with IMPLICIT NONE and add explicit declarations as needed? The code will be safer in the long run. That would be a good solution, for sure, but I don't think I understand the original code well enough to make the required changes. Meanwhile, though, Steve Kargl has suggested a nice fix which just involved moving one block of the code. Allin Cottrell
