\"Module component XX has been defined differently...\"

Well, gone by the wind are those times when i was finding fortran source errors in milliseconds, even ones which others were searching for days. Now i am painfully stuck for exhausting days and weeks (and ones even for a month) myself in the misbehaved code i wrote each and every piece of. For each line of the code there must be now written several lines for self-testing, fool-proofing and graphics visualization, tools and simplified models -- all that serves as some kind of immune system for the code health, otherwise you may sit in front of the screen 24/7 but things will not move at all...Now when i am searching for such hidden error i decided to look at those strange warnings, may be they will shed the light

First points at WINDOW_UPDATE@

WARNING - Module component WINDOW_UPDATE@ has been defined differently here than previously in object file C:\_Main\RK.OBJ (C:\_Main\RK.OBJ)

This is not critically important function and all related functions still seems work fine

But this new one (i missed the day when it started to appear) could be pretty dangerous since it points at major Fortran intrinsics MIN:

WARNING - Module component MIN has been defined differently here than previously in object file C:\_Main\R.obj (C:\_Main\RK.OBJ)

I did not redefine MIN. And where is 'here'? The obj files contain very many routines. Any hints ?

Is this FTN95/Win32? Sometimes it helps to do a complete rebuild. Also a cross-reference using /XREF might help. /DCLVAR can also be useful.

If you have declared a routine (such as WINDOW_UPDATE@) locally then your declaration might differ from one in a standard include file.

Thanks for respond, Paul. Will try your suggestions. Yes, that's Win32 app, I'm even using winapp which I don't like. LOL

What do you mean by complete rebuild? That scares me, I am still rebuilding the code from DOS/VAX VMS since 1997 when I got FTN95 and still not completed making it to work under Windows/Clearwin+! One more such rebuild would take another 20 years !

Other thing I've not understood: how I could declare locally window_update@ which is in own FTN95 library and what for? By mistake? The only case i'd probably wanted to use any functions/subroutines contaning @ as my own ones would be if I was FTN95 developer 😃

A rebuild is when you recompile all the source files in the project.

It is possible to declare (or use) a routine locally as though it were a function (say) when in fact it is declared as a subroutine in an include file.

Still searching what FTN95 found in mere few milliseconds 😦 Can compiler be made to be more specific? 850 subroutines is a lot for human, each my OBJ file contains many subroutines so the words 'defined differently here' points just to the sky. Keeping and compiling each subroutine as separate file would be absolutely impractical. At the end, this ability to catch more bugs then all other compilers combined is what we love FTN95 for.

If rebuild (the word probably comes from PLATO terminology?) is just the recompilation then i do that 100 times per day because i do not use PLATO and recompile all using BAT files, takes just 5 seconds

I think jalih had such error too. Was it fixed, jalih?

Dan,

You could try the following scan and see what pops up. If you work through the list of occurrences it might help.

find /i /n '%1' *.f95 >%1.tce notepad %1.tce

John

Another thought...

Do you delete all *.mod files at the beginning of your batch file? This ensures there is no cyclic dependency.

John, Paul, Did not find anything suspicious so far but your suggestions were interesting and useful for future, thanks

The 'find' command selected me 2008 WINDOW_UPDATE@ occurrences and though no suspects were found, observing such structured file was more pleasant then clicking via whole Fortran text till the nausea

I perform very often two compilations to make sure the dependencies will not ruin the EXE. But because the amount of modules is growing and growing and they depend on each other I'll probably need to switch one day to PLATO. (/On the side note - wasn't introduction of modules in Fortran kind of deadly or even fatal design mistake of Fortran Standard Committee? Modules killed complete freedom of Fortran 77 functions/subroutines. Wasn't it impossible to make allocatable arrays without losing this freedom?)

By the way /XREF is indeed useful but due to numerous include files i use it encodes the numbering better then 256bit encryption LOL

As to /DClvar i instead use /undef (or /checkmate) which is even more powerful then 'implicit none', it misses to check only those parts of code which will not be used during the run. But it checks any moves of the code from the intended logic which is typically the result of often extremely hidden bugs. The /DClvar found too many problems and stopped not finishing. All complaints were about not declaring all used subroutines as external. Is this actually always needed ?