Attempting to port a C source written for POSIX to Windows
Pages: 12
@sm9,
Thank-you for posting the pastebin result. Although it shows lots(!) of errors they are really only of two types (both errors, not just warnings):
I don't think I've ever seen a 7-dimensional array in code before!
For whatever reason, what are believed to be arrays seem to be getting confused with scalars. There was an old and dubious style of programming that passed multi-dimensional actual arguments and received them as flattened 1-d array dummy arguments. Maybe you are victim of that here.
Everything in your pastebin seems to be referring to one of two files: mrcc.f and xmrcc.f. I appreciate the licencing restrictions, but is there any way of posting just a few subroutines from those that elicit errors on your compiler?
Also, try compiling the Fortran code in Windows (i.e. from the command line) - NOT in Cygwin. You should be able to write an equivalent batch file that would do the same as that compilation script. Ignore the non-default compiler options in the first instance. Just do the compile part for now - not the linking.
Can you just try renaming mrcc.f as mrcc.f90 and try compiling from the Windows command line:
gfortran -c mrcc.f90
What happens?
Thank-you for posting the pastebin result. Although it shows lots(!) of errors they are really only of two types (both errors, not just warnings):
7562 | ile1=wspc2((iw-1)*12+12)
| 1
Warning: Array reference at (1) out of bounds (12 > 1)
...
Error: Rank mismatch in argument ‘absind’ at (1) (rank-2 and scalar)
Error: Rank mismatch in argument ‘trec’ at (1) (rank-7 and scalar) |
I don't think I've ever seen a 7-dimensional array in code before!
For whatever reason, what are believed to be arrays seem to be getting confused with scalars. There was an old and dubious style of programming that passed multi-dimensional actual arguments and received them as flattened 1-d array dummy arguments. Maybe you are victim of that here.
Everything in your pastebin seems to be referring to one of two files: mrcc.f and xmrcc.f. I appreciate the licencing restrictions, but is there any way of posting just a few subroutines from those that elicit errors on your compiler?
Also, try compiling the Fortran code in Windows (i.e. from the command line) - NOT in Cygwin. You should be able to write an equivalent batch file that would do the same as that compilation script. Ignore the non-default compiler options in the first instance. Just do the compile part for now - not the linking.
Can you just try renaming mrcc.f as mrcc.f90 and try compiling from the Windows command line:
gfortran -c mrcc.f90
What happens?
Last edited on
@lastchance,
The first subroutine that causes the error is this one:
I have tried renaming mrcc.f to mrcc.f90 and running the native windows gfortran (the one provided with the mingw64-compilers). However, it throws even more errors, with some errors about the lines that are started with * symbols (I think the compiler is reading those lines for some reason even thought they are comment lines?).
Also thanks to all of you guys for helping me throughout this!!
The first subroutine that causes the error is this one:
|
|
I have tried renaming mrcc.f to mrcc.f90 and running the native windows gfortran (the one provided with the mingw64-compilers). However, it throws even more errors, with some errors about the lines that are started with * symbols (I think the compiler is reading those lines for some reason even thought they are comment lines?).
Also thanks to all of you guys for helping me throughout this!!
@sm9,
That code is in truly ancient Fortran! Non-standard Fortran 77 by the look of it! It's not even free-form input! Comments these days start with a '!' and the code statements no longer have to begin in column 7. Things like .eq. have long been replaced by ==. There's at least 6 levels of nesting starting on line 24 and some of those arrays do, indeed, have 6 dimensions. Since Fortran 90 you've been able to use modules rather than long argument lists like that.
The #include line is letting the c pre-processor run through it first by the look of it. I haven't got a copy of that included file, so couldn't even hope to compile it because there's lots of array dimensions and file units missing.
Sorry, @sm9, but that code isn't worth porting. Rewrite it in its entirety. That style of coding has long gone.
If you supply the file MRCCCOMMON then I'll have another go at compiling it. (There's too many parameters missing without.) But I think you would be better rewriting the code.
That code is in truly ancient Fortran! Non-standard Fortran 77 by the look of it! It's not even free-form input! Comments these days start with a '!' and the code statements no longer have to begin in column 7. Things like .eq. have long been replaced by ==. There's at least 6 levels of nesting starting on line 24 and some of those arrays do, indeed, have 6 dimensions. Since Fortran 90 you've been able to use modules rather than long argument lists like that.
The #include line is letting the c pre-processor run through it first by the look of it. I haven't got a copy of that included file, so couldn't even hope to compile it because there's lots of array dimensions and file units missing.
Sorry, @sm9, but that code isn't worth porting. Rewrite it in its entirety. That style of coding has long gone.
If you supply the file MRCCCOMMON then I'll have another go at compiling it. (There's too many parameters missing without.) But I think you would be better rewriting the code.
Last edited on
@lastchance Yeah you are right, I am moving to alternative softwares. I tried compiling the code on a native linux virtual machine, where it is supposed to compile fine, and even there, it throws multiple errors. It's a real shame that scientific programming is stuck to old codes.
there are plenty of up to date programs for common tasks. If its something way, way out there that no one else does and the original authors abandoned it too, well, you are either out of luck or in for a fight to get it up and running again. Its usually possible to load up a computer with tools from the correct era in linux. It is much harder in windows; its a chore to find a copy of something like visual studio 5.0 and get it working on a win98 box (even a vm).
I have had pretty good luck with relaxed compiler settings and very old c++ code. But some languages are a no-go.
I have had pretty good luck with relaxed compiler settings and very old c++ code. But some languages are a no-go.
Last edited on
Topic archived. No new replies allowed.
Pages: 12