Module files usage and dependencies

[Vladimir_F_1]

I have a shared library in which the top module looks like this:

module PoisFFT

use Precisions
use Parameters

use PoisFFT_SP, PoisFFT_Solver1D_SP => PoisFFT_Solver1D, &
PoisFFT_Solver2D_SP => PoisFFT_Solver2D, &
PoisFFT_Solver3D_SP => PoisFFT_Solver3D

use PoisFFT_DP, PoisFFT_Solver1D_DP => PoisFFT_Solver1D, &
PoisFFT_Solver2D_DP => PoisFFT_Solver2D, &
PoisFFT_Solver3D_DP => PoisFFT_Solver3D

end module PoisFFT

I have now a problem referencing this library from another program

  use PoisFFT

  referencing PoisFFT_Solver3D_DP or PoisFFT_Solver3D_SP and some integer parameters defined in module Parameters.

This works for gfortran and Oracle Solaris Studio just by supplying the poisfft.mod file. However ifort complained it cannot find module Precisions. I copied all *.mod files in the include path, but now I get.

poisson.F90(379): error #6404: This name does not have a type, and must have an explicit type. [POISFFT_PERIODIC]
bounds(i) = PoisFFT_PERIODIC

This integer constant is defined in the module Parameters. There is another module named Parameters in the software that uses the library, is this a problem? It works with other compilers.

[TimP]

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.

[Vladimir_F_1]

Everything is compiled with ifort, of course. The other compiler versions are completely separate pairs library - end software.

[Vladimir_F_1]

Also, I inadverently removed my products from the Premier Support when I tried to look around for the first time. How can I get them back?

[Vladimir_F_1]

This works as a workaround, but it is an obfuscation and one has to anticipate the future problem beforehand. use Parameters, PoisFFT_Periodic => PoisFFT_Periodic, & PoisFFT_Dirichlet => PoisFFT_Dirichlet, & PoisFFT_Neumann => PoisFFT_Neumann, & PoisFFT_DirichletStag => PoisFFT_DirichletStag, & PoisFFT_NeumannStag => PoisFFT_NeumannStag

[TimP]

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.

[Vladimir_F_1]

Thank you, Tim, I registered the product again and it worked.

[Steven_L_Intel1]

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

[Vladimir_F_1]

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. More about this (more generally) in com.lang.fortran

[Steven_L_Intel1]

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

[jimdempseyatthecove]

>>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

[IanH]

Isn't that what Vladimir was doing?

[jimdempseyatthecove]

>>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

[Steven_L_Intel1]

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.)