Unexpected LNK2019 Error

Unexpected LNK2019 Error

I just purchased Intel's Parallel Studio XE 2013. Upon attempting to build old Fortran code in this new compiler, I receive the following error "LNK2019: unresolved external symbol _MAINC referenced in function _Main_" and the related "fatal error LNK1120: 1 unresolved externals"

I'm a little confused by this linker error because MAINC is a subroutine defined in the single source file that I am using. Most of the lnk2019 errors I've seen on this forum are either due to references to other source files or because mixed programming languages are used. Any tips on resolving this issue would be very much appreciated.

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

Would you mind attaching a ZIP of the project after a failed build?

Retired 12/31/2016

Unfortunately I'm not able to attach the source code for this work. Is there a reason why a subroutine defined in the main program could be called out as an unresolved external reference?



Also, I should mention that I am getting the following warning twice:

warning #6371: A jump into a block from outside the block may have occurred

I don't think this will help with a debug, as the warnings are just referring to a go statement.

I can give you the header file for this work though. MainC is defined in the Module WIDCalc, and the program which calls MainC is at the end. Am I correct to assume that VS refers to the program UTWID when it refers to the function main?

Module WidCalc


            subroutine MAINC


                        Subroutine WriteResult

                        Subroutine DeAlloc

            End subroutine Mainc

            Subroutine FileOpen(IFileName)


                        Subroutine skip_hashlines

                        Subroutine Alloc

Subroutine Alloc2

                        Subroutine VCheck

            End Subroutine fileopen

Subroutine WriteInj

Subroutine DoIt(tc)

Subroutine ccalc(lam,x,N,c0,cc)

SubRoutine lambdaUpdate(N)

Real(8) Function lambda0c(dp,dg,rhop,rhol,mu,v,f,Hin)

Real(8) Function lambdac(lambda0,sigma,e,b0,b1,b2,Nr)

Real(8) Function ttime(sig,por0,pcr_typ,porcr,ttu)

Real(8) Function ParCop(R)

Subroutine radgrid(r1,r2,N,r,dr)

Logical Function StopCheck(alpha,t)

Subroutine Inittt

Subroutine Initttg

Subroutine Initttfp

SubRoutine qpUpdate(R,q,p)

Subroutine Calc_Core()

Subroutine Calc_V_unfrac()

Subroutine Calc_GOH()

Subroutine calc_H_longitudinal_frac()

Subroutine calc_H_transverse_frac()

Subroutine calc_V_frac()                       

Subroutine calc_V_fracpack()               

SubRoutine calc_Rl_Vert

Real(8) Function NDC(dg, kfp)

Real(8) Function Frac_bfp(kmh,kr,lfp,gpk,wfp)

End Module widcalc

Subroutine PGFellipse2(Lft,layer)                       use widcalc

Subroutine Find_Cumulative

Real(8) Function fast(lff,layer,lthh)                      use widcalc

SubRoutine calc_RintandRcc

Real(8) Function PermDecl(sig,por0,dg,dp,df)

FUNCTION hand_fpe (signum, excnum)              USE MSFLIB

Program UTWID                                                USE DFPORT     use widcalc     USE MSFLIB


        FUNCTION  hand_fpe (sigid, except)

           !MS$ATTRIBUTES C :: hand_fpe

           INTEGER(4) hand_fpe

           INTEGER(2)  sigid, except



      Call CPU_TIME(begin_time)

      Call Date_and_Time(startdate, starttime)

           Call mainc

      Call Date_and_Time(enddate,endtime)

      Call CPU_TIME(end_time)

End Program UTWID

You define subroutine MAINC in module WidCalc; you need to have a use WidCalc statement in program UTWID to be able to access it, which you appear to have in your outline (the formatting originally confused me), so without having access to the original source code, I can't see anything obviously wrong.

That it is trying to call _MAINC and not _WIDCALC_mp_MAINC tells me that the caller of MAINC hasn't done a USE WidCalc, even though you show that in the outline. Please check your actual code to see if that's the case, as outlines and paraphrases are often, I find, not representative.

Retired 12/31/2016

Thanks Steve, that did it!

Glad to hear it. Yet another example of why descriptions and paraphrases can be misleading.

Retired 12/31/2016

Leave a Comment

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