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

Please help with error LNK2019

Nicolas_M_1
Beginner
1,380 Views

 

Hello, I am trying to build and compile a Fortran 77 program in Visual Studio 2013, using Intel Fortran.

The program consists of a main .for file, and many .for and .f subroutines. To run it, I create a new Fortran console project, and load all the .for and .f files. Then, when I try to build, I get the following error:

Error    1     error LNK2019: unresolved external symbol _MAIN__ referenced in function _main    libifcoremdd.lib(for_main.obj)    
Error    2     fatal error LNK1120: 1 unresolved externals    Debug\test.exe    

 

What am I doing wrong?

 

0 Kudos
5 Replies
jimdempseyatthecove
Honored Contributor III
1,380 Views

This indicates that none of your .for files contains a PROGRAM statement.

In years (decades) past a PROGRAM statement may have been implicitly assumed.

Note, this may not necessarily be your situation as you may have a collection of library routines intended to be incorporated into your program (file with PROGRAM statement). In many of these older files (libraries), the input and output varied so much between systems, that this part was left out and became the responsibility of those using the library. Please consult your documentation (which if you are lucky is documented as comments in the library source files).

Jim Dempsey

0 Kudos
Nicolas_M_1
Beginner
1,380 Views

Thank you for your response. The files are to be called as subroutines from within the main program. 

0 Kudos
mecej4
Honored Contributor III
1,380 Views

Nicolas, did you remember to write a main program to call the same DLL subroutines as those that you had linked with Abaqus earlier? 

jimdempseyatthecove wrote:

In years (decades) past a PROGRAM statement may have been implicitly assumed.

This feature is still there. As Faulkner wrote, "The past is never dead. It's not even past.".

There was a recent report in one these forums about a Fortran compiler (I don't remember which, Intel or another) detecting two main programs in the following code:

subroutine sub(i)
i=i+3
return
end
end

do i=1,5
   j=i
   call sub(j)
   write(*,*)j
end do
end

Removing one of the duplicate END statements will leave a complete program that can be compiled and run.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,380 Views

In the card deck days, you could place a batch of implicitly assumed programs in the hopper and the compiler/linker would process and run these sequentially. Your last post seems to indicate that from the compiler's perspective the old feature is still there, ..., but from the Linker's perspective the "batch" is linked together, thus producing the duplicate symbol for whatever the compiler uses for default PROGRAM.

It might be helpful if there were a compendium of error messages presented by old programs together with the common causes and corrective actions.

While this forum may have most of this information, it is not organized in a manner to facilitate reader locating the appropriate thread. The Search is impractical to use for this purpose (at least as it stands now).

Jim Dempsey

0 Kudos
Brooks_Van_Horn
New Contributor I
1,380 Views

You said...

Greetings Brooks V.,

Comment by jimdempseyatthecove:

In the card deck days, you could place a batch of implicitly assumed programs in the hopper and the compiler/linker would process and run these sequentially. Your last post seems to indicate that from the compiler's perspective the old feature is still there, ..., but from the

...

 

Unless the auto forum responder has a problem. But Jim, if not then I think you may be reading multiple threads and getting confused.  I've not said anything about the topic you responded about; however, Alison did. My real comment to her(?) was about incorporating the MS gdi libraries in the link include statement.

 

Broooks

0 Kudos
Reply