"Phantom declarations" causing compile errors ?

"Phantom declarations" causing compile errors ?

I am currently evolving a new project out of an existing one (still retaining the existing one as a separate project)

In the process, some modules have been removed. Retained variables declared in these modules have been relocated into new modules.

In one of my subroutines I accidentally left the USE statement for one of the deleted modules (name of module was "site_variables").

When trying to compile this subroutine, I kept getting messages that "The same named entity from different modules and/or program units cannot be referenced. [xxx]" (xxx = the variable affected names).

Took a while to track down the problem

- repeated searches of the all source files in the new project found only a single declaration of the affected variables (in the correct new modules).

- The fact that I had a "USE site_variables" statement, but no "MODULE site_variables" in the project was not reported as a syntax error.

- Eventually tracked the problem down by removing the USE statements for the new modules that declared the affected variables. The doing a full project build, I got messages such as

"error LNK2019: unresolved external symbol SITE_VARIABLES_mp_SGY referenced in function _SCENARIO_PR" (SGY being one of the affected variables). Hence the clue that "SITE_VARIABLES" was the problem.

Of course, I had to fix all the other syntax problems before I got this far!

What puzzles me is:

### First: HOW does the compiler relate "SITE_VARIABLES" and "SGY" when the original module ("SITE_VARIABLES" - that did contain "SGY") had long since been deleted from the new project?

The module "SITE_VARIABLES" (with a declaration for the "affected variables") does still exist in the original project. BUT that is a completely separate project, with source files in a separate directory on the HD. The ONLY connection I can find is that both are shown as (separate) projects on the "Start Page".

Makes debugging difficult if the compiler is reporting "same named entity from different modules" errors due to declarations in totally unrelated projects (without giving any clue that this is the case).

### Secondly: Why does the "USE site_variables" statement not produce a syntax error, if there is no "MODULE site_variables" in the current project?


7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

In the past I was once getting similar errors when I didnt fully delete all debug/release intermediate files (it seems sometimes, particularly when manipulating modules, the debugger may not rebuild correctly and retain some old mod files). I found the most reliable way to avoid such problem was using windows explorer (delete debug/release dirs), rather than rely on the 'clean' facility, or, on CVF. this occured very rarely - but it might help.

Snap - thanks.

I just checked the Debug directory & indeed, as you indicated, "site_variables.mod" is still there (with references to SGY & the other affected variables), despite the actual module long having been deleted from the project.

Scarcely desirable behaviour?

Caused me no end of frustration searching round & round in circles trying to find the offending "double" declarations (that did not exist) in the current source code. To ensure it wasn't too easy for me, there was no hint that the long deleted "site_variables" module was the cause of the problem, until I got to the linking stage - but of course I could not get there till I fixed the syntax errors due the "phantom" references to the old module (Catch 22 ?)

Any chance of a system fix to remove .mod files for modules that no longer exist in a project?


its probably difficult for a compiler to determine what used to be a dependency (eg, an old mod file) vs some file the user may legitimately put there.
You can always try rightclick-clean on the project - that allegedly removes dependencies. But I think problem would occur if you delete a module-defining *.f90 file from a project without cleaning the project first. at this point the old mod file becomes 'orphaned' and is no longer associated with cvf. So it is difficult to have full automatic clean unless the compiler is set to delete entire directories or everything in them (eg debug).

That is what Build..Rebuild does. It deletes all the .obj, .exe, .dll and .mod files.

Steve - Intel Developer Support

Many thanks, Steve.

Had never struck this type of problem before, so I had missed that one. Solution makes sense - once you know it :-)



I am not so sure Rebuild All (or Clean) will remove the intermediate files (.mod,.obj,.sbr) for a module (in a separate file) that has been removed from the project (ie, file no longer in project). Indeed I tested that and it does not occur.

Of course if the module is deleted from a file that remains in the project then it will be removed.

am I right?

Leave a Comment

Please sign in to add a comment. Not a member? Join today