LNK2019: unresolved external symbol __imp__ VF 11.1?

[Darrell]

Just upgraded to 11.1.48 on Windows XP. Recompiled a C++ wrapped Fortran DLL with generate interfaces turned on got
error LNK2019: unresolved external symbol __imp__MYSUBB@448 referenced in function _MYSUBA in file mydll_lib.lib

* Where did the _imp_ come from? How can I make it go away and work like it did before?

As frustrating as "it used to work" with Compaq Visual Fortran 6 and even Intel 11.0 is, I'd like to thank the new compiler for finding 4 other seriously wrong problems with our interface! I'm sure we've done something stupid again, I just can't find it. I see there is another upgrade to Intel 11.1.51, should I try that? Nothing more fun than comparing declarations of calling arguments until you find the one array that's off but the compiler was right!

mysubb in question is being called from mysuba as two files in the same DLL that also has a C++ wrapper. These two subs are not the public interface that C++ exports, they are internal sub sub routines. However, mysubb is also used by another DLL and is exported so the line
cDEC$ attributes dllexport::mysubb
is present. In desperation, after double checking each calling argument with the generated interface, I removed the cDEC command, deleted the contents of the DEBUG folder, and did a clean rebuild with no luck.

From all the previous discussion on LNK2019, I see our C++ has the uppercase name with
extern "C" void __stdcall MYSUBB

(a) upgrading to the latest compiler will fix this _imp_ problem?
(b) I need to add more stuff to the cDEC$ line because things have changed? The discussion on CVF vs "C" vs stdcall is not clear since we seem to be using all 3?
(c) I can't sit on the fence and need to call the DLL from the DLL if cDEC is present?

workaround: turn off generate interface blocks which then generates the expected _MYSUBB@448 in the .obj file

We're using /iface:cvf I saw some discussion of Fortran 2003 Bind(C) but at the moment we have to support both the old and new compilers with our code. The above mentioned good finds by generate interface blocks still work in the old compiler but F2003 would not.

I made a separate .exe project, put all the code in it, set all the compiler options the same, and it works! Which gives 3 scenarios:
1. stand alone Fortran exe with all the code
2. C++ wrapped Fortran DLL that calls sub sub routine that is also exported by another DLL
3. DLL that calls another DLL

[Steven_L_Intel1]

The __imp_ means that a DLLIMPORT directive was seen for MYSUBB and you have not linked to the DLL import library from the DLL that exportrs MYSUBB. I would expect identical behavior from CVF in the same circumstances. Perhaps you have not correctly rebuilt all the sources in the desired confiiguration.

Note that if you USE a module with a DLLEXPORT directive, that turns into a DLLIMPORT. CVF did that too.

[Darrell]

To clarify: _imp_ means it's looking for the imported routine exported from the DLL.
Adding the DLL's .lib to the project makes the linker error mesage go away!

Now the same source code file is still there in the project. The answer is to delete the .f file and add the .lib until we painted ourselves into a corner as shown below. One file generates _SUBA@123 while the other generates _imp_SUBA@123

We have no DLL Import commands of any kind, no Use statements, and no Modules, only cDEC$ DLLEXPORT directives.

* What are the rules for implicit importing?

When we added the .lib to a project folder, Visual Studio prompted us to add a new custom Build Rule!?! We clicked on No thanks.

* Where are these Build Rules found?

Scenario:
DLLa calls DLLb
DLLb exports subroutines c & d
[DLLb wrapes subroutine c in C++ and exports that too so it can be called from java via JNI]

DLLa calls both c & d no problem because it's project points to the .lib
* DLLb calls subroutine d directly from subroutine c which doesn't compile because it's exported?!?

This scenario used to work with CVF6 & Intel 11 before we upgraded to 11.1.051.

I think once we get the rules straight, it will work everywhere again. Thanks!

[Steven_L_Intel1]

I think at this point I'd like to see a ZIP of an example VS Solution that shows the problem you describe. I don't know why you should have been prompted for a build rule, but I'm not exactly sure what you did.

The only "implicit DLLIMPORT" is when you USE a module that contains DLLEXPORT directives.