link: failure to find a module?

link: failure to find a module?

Build ends with many "unresolved external symbol" errors. All of these refer to Winteracter routines invoked by USE statements. Winteracter documentation, in a generic discussion of "third party" environments (meaning here VisualStudio.NET etc.) says "the directory containing winteracter.mod should be in the module search path used by the compiler when it encounters a USE statement." I am not sure what this means with reference to Intel Fortran / VS.NET. For whatever it is worth, Winteracter.mod exists in the same directory wintlib.if8 that contains winter.lib, and that library has been included in the "include" line in Tools/Options/... of VS.NET. What am I missing?

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

There are two parts to using modules. The compiler looks for the .mod file in the place it looks for include files. You can set this for Intel Visual Fortran in the property page field for "additional include directories". .lib files are not used at this step of the build process

Linking, however, does not use .mod files. You need to tell the linker where to find the .obj or .lib corresponding to the modules AND make sure that it is asked to find that file. There are several ways of doing this. The simplest is to add the .lib file as a "source file" to the Fortran project. Another wsy is to name the library in the "Additional dependencies" field of the Linker Input property page. You can either give the full path here, or just give the library file name (such as winter.lib). If you choose the latter, you need to add the path to the library to the place that the linker looks for such paths, which is Tools..Options..Intel Fortran..Directories..Library Files.

So what you need to do is:

1. Add the path to the Winteracter .mod files to either the project's Additional Include directories property, or add it to Tools..Options..Intel Fortran..Include Directories (probably a better approach as this means you have to do it only once.)
2. Use one of the options above to make the Winteracter .lib visible to the linker.

Steve - Intel Developer Support

I thought I had done all this. Winter.lib has been added to the project as a source file. In Tools..Options..Intel Fortran, c:wintlib.if8,in the "Compiler selection" frame Win32has been entered for Target Platform, Intel Fortran 9.1[IA32] has been entered for selected compiler, and c:wintlib.if8 has been added to both the library and include paths.

It sounds from your comment as if winteracter.modwere in winter.lib, which would be rather strange. The module and winter.lib arefound separately in lib.if8. Imust be misunderstanding you.

Iwas only assuming that my problem occurs because of failure to find the module. What I know for sure is that in the build task list there are 3 lines saying "linking...." followed by a large number of unresolved external symbols, which I recognize as being Winteracter routines. It is reasonable that they would be in winter.lib, but in that case they should have been found by the procedures you advocate. In desperation I tried adding the module asa source file, but not surprisingly that didn't help.

Thanks for your patience!

Modules are not IN libraries. When a module source is compiled, there are two output files - a .mod and a .obj. The .mod is used by the compiler when you USE the module and the .obj, which can be inserted into a .lib, is used by the linker.

Adding a .mod as a source file does nothing. If you can compile the source and get to the link step, modules are not an issue. So what you have is a link issue.

If you posted a couple of the linker messages with the names of the unresolved routines, that might give me a better clue. First, are you using a version of Winteracter designed for Intel Visual Fortran? You can't use a CVF version. Since you manage to get past the compile with modules, I guess you are. Second, since you said that you're migrating from CVF, I'll guess that the Winteracter library you have does not protect itself against your changing the default calling mechanism. Try this. In your Fortran project, select Properties, Intel Fortran, External Procedures. Change the calling convention to "Default" or "Inherit from project defaults". Change the string length argument passing to "after all args". Now rebuild the project. What happens?

Steve - Intel Developer Support

Dear Steve:

Resetting the calling convention f rom "CVF" to "default" solved the problem. Thanks.

Two suggestions about your "white paper" and the (closely related) writeup in the documentation: These both, ifthey had been implemented, probably would have avoided this exchange of messages.

1) "Unless you had a mixed-language application that depended on CVF-specific calling conventions you can set the default calling convention back to the default, in most cases." My application is pure Fortran.

2) It isnot mentioned that if the CVF project to be convertedcontains .lib's the conversion process does not warn that these must be replaced by libraries compiled under Intel Fortran.

By the way, I have to say that your forum -- at least when you personally reply to messages -- is vastly superior to the premier.intel.com help site.

Thanks again for your prompt help (and for working on Sunday). -- John

John,

I'm glad to hear that I guessed right. I'll keep your suggestions in mind for the next revision of the whitepaper.

This forum is a good adjunct to premier.intel.com, but the latter has many more people behind it (I'm one of them) and has services that this forum can't offer. Really, this forum is not intended as a replacement for Premier, but it is an easy way to get informal help.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today