Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28435 Discussions

can build win32 but not x64, unresolved external

Brian_Murphy
New Contributor II
628 Views
error LNK2019: unresolved external symbol CheckFileProperties referenced in function CheckKey

This is a Fortran calling C problem.  win32 will build, but not x64.  I've attached DUMPBIN's for the win32 and x64 LIB files for the c++ DLL I am calling from fortran.  I hope someone can point out what I'm doing wrong.

Here is what I see in the dumpbin's for the unresolved function.

32
    _CheckFileProperties@4
64
    ?CheckFileProperties@@YAHH@Z (int __cdecl CheckFileProperties(int))

Is my problem most likely in my source code, or in my visual studio settings?

0 Kudos
4 Replies
mecej4
Honored Contributor III
621 Views

The decoration @@YAHH@Z added to the end of the subroutine name is the result of compiling a C routine with C++ linkage, probably the result of not surrounding the prototype declaration of the routine with extern "C" {} . Since you did not show us the source code or a description of how you compiled that source code, that's all that I can say.

0 Kudos
Brian_Murphy
New Contributor II
609 Views

Thanks for the reply, mecej4. 

I have added extern "C" to the c++ declaration for CheckFileProperties and the program will now link for both win32 and x64 builds.  However, when I debug the win32 application I now get stack corruption in fortran, although it is able to finish running anyway.  Is there any way that can be caused by something not right with a LIB file?  During the debug run, CheckFileProperties is not called.  So something else I've done must have broken it.  I've made lots of changes today while trying get the code to build for x64.

The stack corruption happens in fortran right after calling routines in a c++ DLL from a third party vendor.  The vendor has provided both stdcall and cdecl versions of their DLL, but only a single LIB file.  I am using the stdcall DLL when I run my application.  That's why I wonder if the LIB file could be causing this.

0 Kudos
IanH
Honored Contributor II
600 Views
I don't understand the connection between the original post and this latest problem.

Are your calls to the DLL functions consistent with what those functions require?
0 Kudos
Brian_Murphy
New Contributor II
586 Views

I apologize, IanH, for the lack of connection.  This is wac-a-mole where solving one problem makes another pop up.  This thread has concluded successfully, and if need be I will start another for the new problem.

Brian

0 Kudos
Reply