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

Using global variable in spec. expr. yields "Unresolved External"

Uwe_H_
Beginner
335 Views

After a compiler upgrade from 2015 to 2016 I got a linker error "unresolved external" when building in debug mode, but not in release mode. The .sln contains two projects, one exe and one dll. The exe does nothing but calling a single function from the dll. In the dll is a module containing global variables. One of those is used in another module as the size of an automatic array. This global variable is reported as an "unresolved external symbol MGLOBALS_mp_THEBAD" when linking the .exe-project (which does not have any reference to that variable). The error disappears when adding a "USE MGlobals" inside the function having the automatic array. Is there anything wrong with the code?
I´ve been able to reproduce this in a minimal example - here is the code:

MODULE MGlobals
  IMPLICIT NONE
  PRIVATE
  SAVE
  integer, public :: theGood, theBad, theUgly
END MODULE MGlobals

MODULE MyModule
  USE MGlobals
  IMPLICIT NONE
  PRIVATE
  SAVE
  public doAny
  CONTAINS    
    LOGICAL FUNCTION doAny()
      doAny=doSome()
    END FUNCTION doAny

    LOGICAL FUNCTION doSome()
      ! use MGlobals !!!!! needed in ifort 2016 to make it work !!!!!
      implicit none
      real :: myArr(theBad) ! THIS usage triggers the error (is it not a valid specification expression?)
      doSome = theBad.eq.66
    END FUNCTION doSome
END MODULE MyModule

MODULE MFunctions
  USE MyModule
  IMPLICIT NONE
  PRIVATE
  SAVE  
  public :: Execute  
  CONTAINS    
    LOGICAL FUNCTION Execute()
    !dec$attributes dllexport, alias: "Execute":: Execute
      implicit none
      write (*,*)'Executed!'
      Execute=doAny()
    end function Execute
END MODULE MFunctions

program ExeProject
  use MFunctions
  implicit none
  logical res
  res=Execute()
end program ExeProject

It seems that a full rebuild is necessary after each code change to have an effect.

Thanks for any insight on why this happens!

0 Kudos
4 Replies
Steven_L_Intel1
Employee
335 Views

I can reproduce this - seems to be specific to building the EXE with /debug. We'll investigate.

0 Kudos
Steven_L_Intel1
Employee
335 Views

Escalated as issue DPD200414030.

0 Kudos
Steven_L_Intel1
Employee
335 Views

Escalated as issue DPD200414030.

0 Kudos
Uwe_H_
Beginner
335 Views

Thanks, Steve!

0 Kudos
Reply