Visual Studio 2010/Intel Composer XE 2015 Update 6/x64-bit tools.
I have a multiple FORTRAN modules in separate .F90 files all combined into one static .lib, say "mod3.lib".
After compiling and generating this library I see all the .mod files and the static library.
I have some other source code , also compiled into, static libraries that "USE" these modules.
I then link the various static .lib files (including mod3.lib) and a main program together.
The problem is I am getting "undefined externals" at link time - and the externals are all functions from the modules in mod3.lib
Doing a "dumpbin /all" of mod3.lib only shows the names of the modules as external symbols. The functions themselves are not visible. What am i missing here????
Are you making calls/references to the module procedures (functions and subroutines) without a USE statement for the module that contains them? In other words, are you attempting to use module procedures as external procedures?
No I am including a "USE" statement in the other FORTRAN libraries that "USE" the modules.
I just can't see what is going wrong. I suppose I don't understand why I can't see the expected symbols in the static library compiled from the various .F90 files that define the MODULES.
From what I understood modules just generate .mod files that are essentially the platform/compiler dependent FORTRAN equivalent of C++ headers files and that functions "in" a module are compiled just like any other function.
Since you have not shown us any source files yet, the following may be a shot in the dark:
Have you, by chance, declared the module subroutines and functions as EXTERNAL elsewhere? This could have happened if you started with Fortran 77 code and gradually converted the external subroutines to module procedures.
You also have not shown us the actual text of the error messages. This is critical in helping us help you. It would also help to see a complete build log (the buildlog.htm files from the Debug or Release folders, NOT what gets echoed to the Visual Studio build window. Put all this in a ZIP and attach to a reply here.
I agree I am not giving people enough to work on to help in solving the problem!
I am helping a co-working port a somewhat complex project from the Visual Studio 2005 era and the source code is completely proprietary. He throws his hands in the air, I run over to try and help - I think we all know the scenario!
I will work on a reproducer.
Problem resolved. This was a case of mixing up 32-bit and 64-bit libraries. The project was a bit of a mess.
At least I did learn about how functions in a module are name mangled.