unexplained unresolved references

[martymike]

We are trying to move our product from using CVF 6.6B and MS C/C++6 to IVF 9.1 and MS C/C++ 8 (along with changing the versions of Visual Studio that we are using). I have successfully built several small programs, and am trying to build a very large dll. To do this required creating 16 projects in a VStudio solution. Some of this has to do with programs that generate header and include files from data files, and some C sources built into static libraries. There are are 4 projects that compile Fortran sources. I have separated them becauseI want to use slightly different options for one set than the other (just warning settings), and I want to build another dll (when I get this one working) that uses most of the same files, but links to different dll's; since all three of these groups use some of the same modules, it seemed like a good idea to build the modules separately. So there are 4 pertinent projects (summarizing, and repeating a bit):

eMod - builds a static lib of most of the modules used by files that will be in the dll (60 files)

eFtn - builds a static lib of files that use the modules in eMod (480 files)

eFort - like eFtn, but with more stringent warning settings (270 files)

eng - builds the dll; includes the libs above (and others with C source files); compiles 19 source files that are unique to this dll (it is my intent, if this ever works, to use the above static libs with another dll build that compiles a different set of sources and links to some different dll's)

The problem is that I get thousands of unresolved references. They are all to module data and contained routines, but not all of them. I cannot figure out why some of them work and some do not. All the modules are in the eMod build.

I've attached6 example modules (I'd have just inserted them here, but apparently you cannot paste in these messages).Each of these modules actually resides in a separate file (I've deliberately chosen 6 very small modules - some are hundreds of lines long). I've stripped out the comments. I also removed a block from each that defined a DLLIMPORT attribute for each data item if DLLI is defined for the compiler - we never use that (it is a remnant of something developed for an old version of the CVF compiler that we just never got around to removing - I only mention it to be thorough).

When I build eng, all the module data items in the first three modules that are exported - except PQM in CMPR_MODULE - show up in a LNK4049 or LNK4217 warning saying locally defined symbol imported. So far so good.

All the module data items in the last three modules show up as unresolved references. We are currently building this code with CVF 6.6B et al with no problems, although in one project and not via a bunch of static libs.

Obviously I could try mashing all these together in one project - and I will if I have to - but the separation provides some benefits, and it's too many files to "just play around with". Any ideas?

[Steven_L_Intel1]

Just seeing the source is not too helpful. We'd need to see a ZIP of the whole solution including all of the projects and sources. If it comes to that, don't do it here. Instead, open an issue with Intel Premier Support and attach the ZIP to your issue.

Some things to look for.

• Since you were using CVF, perhaps you used the automatic project converter "Extract Compaq Visual Fortran Project Items". One of the things this does is set the calling convention to CVF, which is different from the Intel Fortran default. If you changed this on some projects, or created new projects on your own, this might not be set and you'll get linking errors. In each Fortran project, right click on the project, select Properties, Intel Fortran, External Procedures. Set the Calling Convention to Default.
• Did you set up project dependencies? Right click on a parent project, select Project Dependencies. Check the boxes for each project that is a "child" of this project. This causes the output library of the child project to be linked with or combined with the parent.

[jimdempseyatthecove]

1) Make sure your Main has the other projeces as dependencies.

2) Make sure none of the projects (project files) are marked exclude from build

3) Make sure all your projects are building to the same configuration (project settings)

If you recently upgraded VS it's conversion utility doesn't always convert properly especially the 1) and 3) are often wrong after conversion.

Jim Dempsey

[martymike]

I replied a little while ago, but it seems to have disappeared, so let's try again, ... (let's see if I can remember everything I said the first time)

Thanks, Steve and Jim, for your suggestions, but I'm afraid it is nothing that simple.

I did not use the conversion utility. I created the projects myself. I've created 71 projects so far, not just the 16 in this particular solution that I am writing to you about.

I am using the CVF calling convention - deliberately. Our application has a mix of Fortran and C code and I just did not want to deal with changing all the interfaces. The calling convention is set at the project level, and I have checked them all.

The project dependencies are set. This can be confirmed when the solution builds, which I have done several times, including complete rebuilds. Also, the buildlog.htm file that gets created shows the link command that is used and all the lib files are present.

It is not that a library is missing. It is there. There are many modules in the library. Some of those module variables and module routines are found by the linker, and some are not. That is the mystery. The granularity of the problem is on the module level, not the individual item, i.e. while I see no reason for it to have a problem with some items and not others, if there is a problem with an item, all the items in that module seem to have a problem. It looks like those modules are just not in the library. The buildlog.htm file for THAT project contains commands showing each file compiles, though, and the command to build the library references each of the (60) objects.

I have to step away from this for a week because of a business trip; before I did I thought it was worth a try to see if anyone on the forum might have had a related experience. If neither one of you nor I have a brainstorm between now and when I get back, I'll package something up for premier support, as Steve suggested.

[Jugoslav_Dujic]

Um, I'd start with

dumpbin /symbols Suspicious.lib > temp.txt

and

dumpbin /symbols UsingSuspicious.obj > temp2.txt

and compare whether the names of reported symbols match. If they do, perhaps you're linking A Wrong Library? If they don't... check out why.

I have a hunch that maybe it's all just due to a typo in a path or library name reference, rather than a compiler or linker mandelbug.

[Steven_L_Intel1]

Check the build logs to see if the libraries are actually being used. If you are using VS2005 and have a C++ project that depends on a Fortran project, you need to install VS2005 SP1 to have that work.

[martymike]

I spoke with someone at Microsoft and I understand the problem. I'm writing this just in case someone reads the thread and is curious - I'm no longer asking a question.

The sources that I have that define modules contain DLLEXPORT compiler directives for some of the symbols defined there. When I build this into a static library, the DLLEXPORT commands are not kept, but the designation of the symbols as imported is kept. The linker then cannot resolve that the local names and the names marked for import are the same. You simply can't do that, i.e. you cannot use a static library and expect export directives to be kept.

I've stopped building the library, and am just keeping all the object in one directory and then including them in my eventual build using as *.obj. No problems anymore.