compiler unable to find module and symbols

[Joseph_V_]

Hello,

I can compile my sources on Linux with the ifort compiler without any problems. 

However, when I use the same Makefile or when I use the Visual Studio IDE with  Visual Fortran Compiler XE 13.0.1.119 the compiler complains about one particular module thus:

path\to\SOURCE\myfortranfile.f90(12): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [fn#fn]

What I find baffling is that the name of the module is mentioned as fn#fn and as far as the code goes, since it compiles without issues on Linux, I'm confident that the sources themselves have no serious issues. 

Anything else I need to look out for?

Thanks in advance.

[Arjen_Markus]

Could you show us the source code anyway (or else a stripped down version that exposes the same problem)?

Without something like that to look at or experiment with, we can only speculate on the causes.

[Joseph_V_]

I tried to create a SSCCE but, this always worked, so I'm not really sure if I can make a reproduceable example and unfortunately, the source itself is proprietary. 

I was hoping that the fn#fn would be clue enough. Any ideas on when this can happen?

At this point, I wouldn't mind working with speculations either as I have run out of ideas. 

Some more information if it helps:

*The module in question has been compiled into a .mod file and is present in the path that I've specified as the "Intermediate Directory"  in Visual Studio.

*I even added this "Intermediate Directory" path in the "Additional Include Directories" option in Visual Studio.

*One of the main differences between this module and other modules that work for me, is the use of "TYPE" The module in question has defined a couple of "TYPE" variables that are composed of other primitive types. 

*Commenting out the bodies of all the subroutines in the module gets past this error.

[Arjen_Markus]

Hm, the use of derived types in a module is not the reason perse for this behaviour. I use them all the time without ever seeing an error message like that. BTW, the compiler complains literally about "fn#fn"?

One thing that might cause a problem is if the module file resides in a deeply nested directory - there are limits to the path length. If that is the case, then I suggest you copy it to a directory that is less deep into the hierarchy and have the Additional Include Directories point to that, as a quick and dirty check that this solves the problem. In the long run you would have to change the directory structure of your project (or you could set the output directory for that module/project to something different than the default, not a very commendable solution as you can easily lose track of things, but it might worth a try).

[mecej4]

I find the error message in #1 rather odd. In particular, the part path\to\SOURCE\myfortranfile.f90 prompts this question: do you really have subdirectories called 'path', 'to' and 'SOURCE'? Did the error message literally end with '[fn#fn]'?

[Joseph_V_]

@arjenmarkus "BTW, the compiler complains literally about "fn#fn"?"

Yes, it literally says "fn#fn"

I'll try to move the folders closer to the root C:\

@mecej4 path\to\SOURCE\ is just a place holder I used. The actual path consists of C:\User .... etc

and yes, it did end with "fn#fn" 

[Joseph_V_]

I tried moving the folders closer to the root C:\ folder to prevent issues with long path names, as arjenmarkus suggested, but that didn't help and I got the same error as before.

[Joseph_V_]

Additionally, I got the same error when using nmake and a Makefile, so it doesn't appear to be a Visual Studio issue.

[FortranFan]

Joseph V. wrote:

Hello,

I can compile my sources on Linux with the ifort compiler without any problems. 

However, when I use the same Makefile or when I use the Visual Studio IDE with  Visual Fortran Compiler XE 13.0.1.119 the compiler complains about one particular module thus:

path\to\SOURCE\myfortranfile.f90(12): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [fn#fn]

What I find baffling is that the name of the module is mentioned as fn#fn and as far as the code goes, since it compiles without issues on Linux, I'm confident that the sources themselves have no serious issues. 

Anything else I need to look out for?

Thanks in advance.

Can you confirm you've covered all the basics in terms of Windows OS (file, folder structures, etc.), how Visual Studio IDE works (its file, folder settings) and how Intel Fortran integrates with Visual Studio?  There is a lot of help online plus you may know of Intel Fortran's help too: https://software.intel.com/en-us/node/524573

[Joseph_V_]

Yes, I have 12 other projects that are way more complicated, with combinations of fortran, c++, static libs, dynamic libs with both C++ and fortran and so on. 

None of them have a problem. Just this one project, and, as mentioned in my last comment, even with nmake and Makefile I have the same error message, so it looks like something to do with the Intel Fortran compiler.

Also, in other cases where the module cannot be found, the compiler actually writes the module name, but in this particular case, it writes out [fn#fn]

In the only other message I found on the forum that mentioned "[fn#fn ]", the poster found that it had something to do with "Andrew File System" - I definitely do not have Andrew File System as I am on a Windows 7 laptop.

[Steven_L_Intel1]

I suspect the fn#fn is a bit of a red herring. What's supposed to be there is the name of the module. Is it possible that you're using the preprocessor and the USE statement is getting a macro substitution?

[Joseph_V_]

I do have other modules "USE"d in my program and they are also compiled the same way that this particular module is compiled and the compiler seems to be able to find them alright, so I don't think it is a macro substitution of the "USE" statement.

Irrespective of where I put the USE statement for the module in question, among other USE statements, the compiler stops always at the USE statement for the module in question.

[Joseph_V_]

Also, if I comment out the bodies of the subroutines in my module, leaving just the subroutine names and the variable declarations, it compiles completely.

However, after the above, to figure out the part that is causing my issue,  if I uncomment certain lines, the compiler itself crashes! Here, the set of uncommented/commented out lines are also inconsistent. Sometimes there is a crash with a particular set, and at other times with another set.

I also get errors such as this:

path\to\my\file\myfile.f90(570): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
1>  CALL Mysubroutine(Mec, n_Net, p_Net, n_Net, k_Net)
1>^
1>[ Aborting due to internal error. ]

[Steven_L_Intel1]

Please provide us with a test case. You can use Intel Premier Support to supply this privately.

[Joseph_V_]

Turns out that it was an issue with that specific compiler. 

Even the linux build caused that specific compiler to crash. 

Now, I've upgraded to composer_xe_2015.1.133 and am trying on Linux first.

However, I get this error at the link stage now:

/intel/composer_xe_2015.1.133/compiler/lib/intel64/libifport.so.5: undefined reference to `for_since_epoch_t'
/intel/composer_xe_2015.1.133/compiler/lib/intel64/libifport.so.5: undefined reference to `for__intermediate_establish'
/intel/composer_xe_2015.1.133/compiler/lib/intel64/libifport.so.5: undefined reference to `for__process_start_time'

I couldn't find any information on those specific errors, so am not sure if I need to link against any other library.

My linker flags are: -static-intel without specifying any intel library.

[Steven_L_Intel1]

Normally those symbols would be found in libifcore. What command line are you using to link?

[Joseph_V_]

All resolved. I had to compile other dependent libraries also using the same compiler/linker options and then it worked fine.

In short, all the issues were only with the 2013 compilers. 2011 and the 2015 compilers worked fine.