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

How to find LNK2019 unresolved external symbol

Bill1
Beginner
643 Views

Hello,

I am working with a very large Fortran program containing several hundred subroutines using Intel Parallel Studio XE 2020 (Beta) and ran into a difficulty today after editing over 500 instances of a variable named MTYP.  The following error occurs:

1>Sourcefile.obj : error LNK2019: unresolved external symbol _MTYP@4 referenced in function _vfe$0003T187$BLK

I obviously messed something up in my editing, but did not see any obvious error in the source file that produced Sourcefile.obj.  Is there any way to tell what function is being referenced in the message: _vfe$0003T187$BLK?  Thanks.

Bill

0 Kudos
4 Replies
Steve_Lionel
Honored Contributor III
643 Views

Yes.  First, "vfe" refers to a "variable format expression. You have something like:

100 FORMAT (<MTYP(I)>I8)

where MTYP is a function reference (or an undeclared array.) The @4 tells you that 1) you have enabled the STDCALL calling convention, which is not the default in Intel Fortran, and 2) the call to MTYP has one argument. You'll typically get STDCALL if you enabled CVF compatibility, or converted a project from CVF. Project properties > Fortran > External Procedures > Calling Convention.

Given the use of STDCALL, you might get this error if function MTYP exists but has a different number of arguments. Or, as I mentioned earlier, you intended it to be an array but didn't declare it as such.

Does this help?

0 Kudos
Bill1
Beginner
643 Views

Hi Steve,

Thank you for the response, and yes this helps.  I found the error by searching again through my edits and indeed it was in a variable format expression.  I missed it as it was located in a lengthy WRITE(6,'()') type statement and with the text coloring in Visual Studio it looked like it was part of a string.  This project was converted from CVF; would there be any advantage to changing from STDCALL?

Bill

0 Kudos
Steve_Lionel
Honored Contributor III
643 Views

I would generally recommend setting the calling convention back to the default. I suppose it doesn't really matter, but I prefer to keep things as standard as possible. You might consider creating a new project and adding your sources to it, as the project defaults have changed over the years and some of the new diagnostic settings might benefit you.

The only reason not to change the convention is if you are mixing with another language or library that uses STDCALL. Note that if you do a 64-bit build, there's only one calling convention.

0 Kudos
Bill1
Beginner
643 Views

Thank you Steve!

0 Kudos
Reply