LNK2019 Errors when Referencing Subprograms within the Curent Module More than Once

LNK2019 Errors when Referencing Subprograms within the Curent Module More than Once

I am encountering LNK2019 (unresolved external symbol) errors when referencing other procedures within a module.  The problem occurs when the other procedure is referenced more than once.  For example, the following code sequence will result in a LNK2019 error for subroutine C_Sub:

module M_Module

contains

   subroutine A_Sub

      ...

      call C_Sub

       ...

      call C_Sub

   end subroutine A_Sub

   subroutine C_Sub

   end subroutine C_Sub

end module M_Module

If I remove the second call to C_Sub, or I create a new module with C_Sub (and appropriately reference C_Sub in A_Sub), I don't have any problems.

What do you suggest?

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

What your describing sounds like a bug. There could also be an error in your program that is not included in the description.

Could you attach your program to this issue or submit it to us through premier support? I am not able to reproduce this behavior in a simple test case.

Thanks,
Annalee
Intel Developer Support

mecej4's picture

Please post code that actually exhibits the behavior that you describe. This example code compiles, links and runs normally:


module M_Module

contains

   subroutine A_Sub

      call C_Sub

      write(*,*)' Returned from call-1 to C_SUB'

      call C_Sub

      write(*,*)' Returned from call-2 to C_SUB'

   end subroutine A_Sub
   subroutine C_Sub

   write(*,*)' In C_sub'

   end subroutine C_Sub
end module M_Module
program tst

use m_module

call A_Sub

end program tst




  In C_sub

  Returned from call-1 to C_SUB

  In C_sub

  Returned from call-2 to C_SUB

The full program is Boeing proprietary. I will need a private thread to send it and evidence that Boeing has a Proprietary Information Agreement (PIA) with you. I'll do the following:
1. Verify that the program runs when the module statement causing the problem is removed (looking for a program error); and
2. See if I can verify that we have a PIA with you from my side.
If you have any information regarding a PIA, that might help me find it.

Hello Gary,

This issue would more appropriate for Intel® Premier Support. If you need help setting up an account, please feel free to send me a private message.

Regards,
Annalee
Intel Developer Support

While I was in the process of creating a clean solution to provide to Intel, I copied my source files over to a new directory, created a new project and built successfully. At that point, I went back to the old solution, Cleaned it, and then Built successfully.
The order of events that got me to the original problem was as follows (using Visual Studio 2005 and Intel Fortran 11.1.060):
1. Build the program (both compiles and links);
2. Change one of the files into a module; and
3. Build the program.

Login to leave a comment.