The .mod file has to be built by the same compiler with the same major version as the file which USEs it. .mod file formats vary, even among gfortran major versions.

On the main page after you log into premier.intel.com you should see a registrations selection where you can confirm which products you have registered. Also on the main page, the Product Access>My profile should give you a list of products available to add to your support categories.

Please provide (either here or through Intel Premier Support) a complete example that demonstrates the problem, and we'll be glad to investigate.

This sounds like a PATH issue (including the wrong module).
Locate all the Parameter.mod file (whatever name is on your system).
Rename all the ones that should not be included by your app (e.g. ParameterSave.mod).
The build
If build succeeds, then this is a path order issue
If build fails, then you have omitted the correct path (or placed the .mod file in the incorrect folder).

Jim Dempsey

I deleted an earlier reply where I said this was an IDE bug - I meant that for a different thread. Sorry.

>>It was a clash of two modules with a same name in a single application. I was lucky it worked for some reasons for other compilers and that it was possible to find a workaround for Intel, but it might have caused more harm in the future. That's why I name-mangled module names in the library.

When this occures, consider making a library with files using one of those modules, then linking to a project built with the remaining files using the other of the modules. You can extend this to building more libraries should you have more than two modules of same name.

IOW isolate collections of compilation units using different same named modues by use of containing them to libraries, which are then linked together to construct the complete applicaiton.

Jim Dempsey

Isn't that what Vladimir was doing?

>>Isn't that what Vladimir was doing?

From the information given it would appear that that was what he was attempting to do, however I believe his information was incomplete (missing nuances).

The error message alluded to was a compiler error message not linker error message. This infers that the name space collision (conflicting INCLUDE) paths was in error as opposed to object file (linker) symbol name collision. This in turn requires (implies) that the intended seperate .mod "library" files were compiled together using the same (and incorrect for one) INCLUDE PATH, .OR., the include path from one project blindly copied from one library project to the other, .OR., user relying on environment variable INCLUDE path and not changing environment variable INCLUDE between compiles.

Note, Library A may be from 3rd party, Library B may be from 3rd party, both may have documented (or installition performed) add installation directory/folder to INCLUDE path. You cannot use same environment INCLUDE path to resolve conflicting file names (Parameters.mod). Instead you must remove these from the environment variable INCLUDE and place into the project (or make file) include paths.

Jim Dempsey

The recommended solution to this is to enable one of the "Use MKL" options in the project properties. This will tell the compiler to add the appropriate MKL include path (there are two dependent on integer size.)