Program will not USE a compiled mod file

[dboggs]

I created this source code in file Test_mod.f90

   Module Test_mod
      INTEGER     :: I1 = 10
      INTEGER     :: I2 = 20
      REAL        :: R1 = 1.234
      REAL        :: PI = 3.14159
    END MODULE

Compiled it, and moved the file to b:\ivfprojects\ModFiles.

Then I created this source code in file UseModTest.f90:

PROGRAM USEMODTEST 
      USE Test_mod
      IMPLICIT NONE     
      PRINT *, 'I1 =', I1
      PRINT *, 'I2 =', I2     
   END PROGRAM

Using visual Studio, I set the project properties > Fortran > Additional include directories to : "b:\ivfprojects\ModFiles".

The source file compiles OK but it will not link: fatal error LNK1120: 2 unresolved externals

1>Debug\ModCallingTest.exe : fatal error LNK1120: 2 unresolved externals. (The complete build log is attached) Sorry, buildlog.htm would not upload. Here is the text: (sorry about the formatting, I can't figure out how to control it)

1>------ Rebuild All started: Project: ModCallingTest, Configuration: Debug Win32 ------

1>Deleting intermediate files and output files for project 'ModCallingTest', configuration 'Debug|Win32'.

1>Compiling with Intel(R) Visual Fortran Compiler XE 12.1.2.278 [IA-32]...

1>UseModTest.f90

1>Linking...

1>UseModTest.obj : error LNK2019: unresolved external symbol _TEST_MOD_mp_I2 referenced in function _MAIN__

1>UseModTest.obj : error LNK2019: unresolved external symbol _TEST_MOD_mp_I1 referenced in function _MAIN__

1>Debug\ModCallingTest.exe : fatal error LNK1120: 2 unresolved externals

I thought this was supposed to work and followed instructions as carefully as I could. What is wrong?

[IanH]

The compiler is finding the mod file ok (if not you'd get an explicit error to that effect early on) and knows that I1 and I2 are module entities (you can tell because of the modname_mp_ decoration that has been applied to the I1 and I2 symbols to get their linker names). Things are failing at the link step - it looks like the linker hasn't been told to search the obj file that was generated when the source file with your module was compiled. - If you have compiled Test_mod.f90 external to Visual Studio, then you would need to pass Test_mod.obj explicitly to the linker, perhaps via the property Linker > Input > Additional Dependencies. You may also need to specify the location of that obj file under Linker > General > Additional Library Directories. Alternatively I *think* you can just add the object file as a "source file" in the project and the Visual Studio build system should pass it to the linker automatically. - If Test_mod.f90 is part of a separate static library project in Visual Studio, then setting the project dependencies (right click on the project for the main program in the solution explorer and select Project dependencies) should be all that is required for both the module search path to be set appropriately and for the linker to be provided with the name of the intermediate static library (well, in recent variants of Visual Studio and ifort at least).

[dboggs]

Thanks Ian, your info helps me A LOT in understanding how it is supposed to work. I now have it working, but not EXACTLY as you describe. After completing all of your suggestions, I still had build error #7002: Error in opening the compiled module file CHECK INCLUDE PATHS (Test_mod), even though I had entered the proper include path as project properties at "all the right properties." What I did, eventually, was to set the VS global default property: Tools > Options > Intel Visual Fortran > Compilers -- Includes window -- add path to the .mod file, IT WORKS! I also found an alternate solution using the VS Project properties: Project > Properties > Fortran > Preprocessor -- Additional Include Directories -- add path to the .mod file AND Ignore standard include path -- YES In other words, the "additional include path" seems to be disabled by the standard include path, so the solution is either (1) setup the standard include path like you want, or (2) ignore the standard include path and set the project additional include path like you want. This certainly seems like a bug to me, and neither one of these solutions has the general applicability that you might need. Shouldn't "additional include path" be something in addition to the standard include path? It behaves like an "alternate include path".

[Steven_L_Intel1]

No, the standard include paths don't disable the additional ones. In fact, the standard paths are looked at after all the others. All I can think is that you mis-entered the path in the project properties.

[dboggs]

No chance, very close to 0, they were entered wrong. I went back and forth, alternately yes/no on the "ignore standard include path" question, and the observed results on project build were success/no success, accordingly. Maybe I have some other obscure setting or disk structure etc. that could be affecting things, but I can't imagine what. If the standard include path is entered correctly, the project builds. No matter what the project include path is. If the project include path is entered correctly and the standard is not, the project builds if the standard is ignored and it does not build if the standard is not ignored. In another day or two I will try another simple test--now that I understand the intended behavior better--maybe on a different computer and (slightly) different IVF version, and see if this is reproducible.

[dboggs]

I cannot re-create this problem on a second computer. I cannot even re-create the problem on the first computer. But, the problem persists on the original project. I do not know how to explain this but am willing to chalk it up to some kind of fluke involving the circumstances of creation of the original project. I am still having trouble about how best to use independently compiled modules in a project but I will begin another thread to pursue that.