Strange linking error in gfortran

[Bosse7]

Hi

I wanted to use an old F77 subroutine package in my new Fotran code and I could compile it with minimal changes but when I tried to link it with the rest of the code I got a strange error from the linker

c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: lmdif1lib.o: bad reloc address 0x20 in section `.eh_frame'

It took some time to reallize that this was due to the fact that inside some of the F77 routines two functions had been declared as
DOUBLE PRECISION ENORM,DPMPAR

where ENORM and DPMPAR were functions in the same package. When I removed this declaration the linking went smoothly.

I have noticed earlier that one should not declare function types inside the subroutine they are used in gfortran but as this was necessary in F77 I missed this declaration when I converted the code. And the error message is not very clear or informative, except that the functions also appeared as undefined references. There is a similar problem with the EXTERNAL declaration.

This is just a hint to others with the some problem or the gfortran developers if they read this. I do not think it is really a FAQ.

 

[zmth]

gfortran,aka gnu fortran,mingw etc. etc. is so full of bugs and discrepancies I don't even see how they can advertise it. Always giving ridiculous ' can't assign to a named constant ' and ' Invalid character in name ' compile or something errors and also one cannot use modules because of the way it needs an extra module file though if one is knowledgeable about command line switches maybe they can get around that error. For example consider the very simple:

if (i==1); then ;print*,1
endif ; end

which is perfectly valid but then gfortran gives
' can't assign to a named constant ' Seems it is most likely to do that whenever have a simple if (...) ; then ; .... constructs so often to render gfortran about useless !!

 

[xwb]

gfortran is maintained by volunteers who give their time for free. There is no big organization behind it providing lots of cash for doing things consistently. If you want a free compiler, it is one of the most up to date ones around but you have to live with its quirks.

If you want to spend money, then you may get proper error messages or you may get the same ones as gfortran.

zmth: your code isn't perfectly valid Fortran. The ; between the ) and the then renders it invalid. I've tried it on four different compilers (gfortran, lahey, silverfrost, ivf) - none of them accept it.

 

[zmth]

ok thanks that was an error but here is example of how atleast using gfortran with code::blocks that it can't open, write or read etc. files to do with module

module inc
contains
subroutine sub1(i)
i=1
end
end module inc

And here is example of gfortran bogus ' invalid character in name ' error

module
contains
subroutine sub1(i)
i=1
end
end

 

[Bosse7]

I started this tread with the intention to help others having strange error messages. I use the free GNU fortran as I am a retired professor developing a free thermodynamic software based on my 30 years of experience and without any economic support. If gfortran did not exist I would not be able to do this so I am very grateful.

Free software is very important as the commercial companies without this would have less need to improve their software and develop new features. All software has bugs, what we as users can do is to report them and hope they are fixed in a future release.

Bosse

 

[FJacq]

@zmth : your examples are always wrong.

Instead of :

module
   contains
   subroutine sub1(i)
     i=1
   end
end

you should write :

module my_module
 contains
 subroutine sub1(i)
   i=1
 end subroutine
end module

=> a module must have a name. And within a module, a subroutine must end by "end subroutine" and the module itself must end by "end module".

Gfortran is a very good compiler. The only (small) trouble I meet with it are the error messages which are not always easy to decode. This is also why I use several compilers like g95, nagfor (Nag) or ifort (Intel).



François Jacq

 

[zmth]

ref
FJacq (Programmer)
20 Sep 15 11:25
@zmth : your examples are always wrong.

Ok i did forget to put the name of the module in that 2nd code but that is the ONLY thing that is required. One does NOT have to have "end module name" or even "end module" but just plain
"end" by itself is enough. And one NEVER has to have end subroutine BUT only 'end' by itself is sufficient. I have verified this many times in gfortran compiler.

 

[xwb]

Although you can use END by itself, END SUBROUTINE subname is recommended. It helps when your program is very long and you see an end but don't know what it belongs to.

With a lot of cut and paste nowadays, it is possible to cut out the end of one subroutine and the beginning of another very easily I've done it on a laptop when the trackpad highlighted and deleted the code all you see is a blue flash but you do not realize that code has been deleted. I got a compilation error but without the END SUBROUTINE subname, I would not have noticed that the chunk of code had been removed. There is always a reason for introducing extra syntax into a language.

 

[FJacq]

@zmth END SUBROUTINE and END FUNCTION are REQUIRED in modules. Only the names of the subroutines or functions are optional ! For END MODULE, the keyword MODULE as well as the module name are optional.

Example with INTEL compiler :

module test
  contains
  subroutine titi
  end
end

coul@b10p5001:~/test$ ifort -c tt.f90
tt.f90(4): error #6378: SUBROUTINE must be present on the end-subroutine-stmt of an internal or module subroutine
end
^
compilation aborted for tt.f90 (code 1)




François Jacq

 

[zmth]

Yes it does sometimes make thing clearer to put ' end subroutine ' rather than just ' end ' for readability. Anyway the original compile error as I stated long ago was found not to be any fault of gfortran but instead code blocks. When i did it right at the dos command line in gfortran direct there was no error.

 

[gRaoul]

Dear Bosse7,

I use FORTRAN 77 (gfortran) to program thermodynamic functions (e.g. polynomial equations to reproduce values of the NIST Thermochemical Tables, Saturation Properties for Water, equations of state, real gas, etc).
I am passionate about the Hydrogen Society (electrolysers, fuel cells, methanation, ...) and am making my way through this discipline (personal development).

Given your professional background I am wondering if you are available for personal correspondence and exchange on this topic.
You can contact me here raoul dot abrutat at-sign bigpond dot com

Thank you
Raoul