Linking to IMKL does not work due to appended @length

[Lars_Jakobsen]

Hi,
I am using IMKL to do FFT and have made a routine (named fftrf)closely following the FFT code examples.
I have previously compiled this code without trouble, however today it started given the error:

"unresolved external symbol _dfti_create_descriptor_1d@20 referenced in function _FFTRF"

when I look in the newly generated object file "fftrf.obj" I can see that it has been named _dfti_create_descriptor_1d@20 while it in theobject filefrom a previous versionwas named _dfti_create_descriptor_1d (without the length appended).

I have not changed any compiler options,I am using /iface:cvf as calling convention,I am using /Qmkl:sequential and I am trying to compile it with version 12.0.3.175 [IA-32]

I have updated to a later version of the intel compilerbetween the two versions(I think the old version was either 12.1.127 or 12.2.154) - should I have changed some settings as well?

Any help is much appreciated.

Regards

Lars

Here is my source code:

subroutine FFTRF(nXi,nXo,X_in,X_out)

[bash]  use MKL_DFTI
  implicit none
  ! -- input variables
  integer                , intent(in)      :: nXi, nXo     ! number of points in X_OUT
  real(4), dimension(nXi), intent(in)      :: X_in         ! real sequence
  real(4), dimension(nXo), intent(in out)  :: X_out        ! fourier coefficients
  ! -- local variables
  type(DFTI_DESCRIPTOR), pointer  :: fftDescHandle
  integer                         :: iret
  
  ! Perform a complex to complex transform
  iret = DftiCreateDescriptor(fftDescHandle, DFTI_SINGLE, &
      DFTI_REAL, 1, nXo )
  iret = DftiSetValue(fftDescHandle, DFTI_PLACEMENT, DFTI_NOT_INPLACE)
  iret = DftiCommitDescriptor(fftDescHandle)
  iret = DftiComputeForward(fftDescHandle, X_in, X_out)
  iret = DftiFreeDescriptor(fftDescHandle)
  ! result is given by {X_out(1),X_out(2),...,X_out(32)}
  
  return
end subroutine FFTRF











[/bash]

[TimP]

I believe the current MKL no longer supports /iface:cvf. If you don't find it in the release notes, you could ask to confirm on the MKL forum.

[Steven_L_Intel1]

The STDCALL mechanism is still supported, but something else is going wrong here. The interface in the DFTI module explicitly specifies the C calling mechanism and a lower case name. The name is properly lowercased but the compiler is appending the STDCALL suffix to it. Let me poke at this a bit more.

[Steven_L_Intel1]

I can't reproduce a problem with Composer XE 2011 Update 5. I do note that MKL does not provide a precompiled version of MKL_DFTI.mod so you have to compile it yourself. If you have not done so recently, please recompile the current version.

[TimP]

When you create .mod files, is it necessary to specify /iface:cvf in order for the .mod files to work with that option?

[Steven_L_Intel1]

No, it is not.

[Lars_Jakobsen]

I tried to install update 1 and update 5 and both resolved the problem, so my guess is that it was introduced somewhere in between these updates and resolved again? The funny thing was that this only happend in release mode, not in debug mode.

Regards

Lars

[Lars_Jakobsen]

I tried to install update 1 and update 5 and both resolved the problem, so my guess is that it was introduced somewhere in between these updates and resolved again? The funny thing was that this only happend in release mode, not in debug mode.

Regards

Lars

[Steven_L_Intel1]

It's possible. Glad to hear that you got it straightened out.

[jimdempseyatthecove]

Lars,

I ran into a similar "funny thing" when I updated from "Parallel Studio 2010" to "Parallel Studio 2011 XE". I happen to do this without firsremoving "Parallel Studio 2010". Nothing wrong with this since in VSyou can specify in the solution/project which virsion to use. I did not notice this (or forgot about this feature). After installation of the upgrade I assumed that my projects would use the newly installed version of the compiler and libraries. I did not notice the issue until sometime later when I then uninstalled "Parallel Studio 2010". Then VS was unable to build the projects. One or two "dope slaps" later it dawned on me as to the ramifications. Could your issue have been related to your solution/project using an old setting?

Jim Dempsey

[Lars_Jakobsen]

Hi Jim,

I can not say forsure if something similar happend to me, butI have not been using version 2010 of intel visual fortran (I am a rockie to intel visual fortran,only began to use it approximately 6 month ago).The error disappered after installation of update 5. However I have been using Microsoft visual studie express c++ 2008 and c++2010- could this be the problem (I use the 2008 shell included with intel visual fortran)?

Also, I tried to install update 3 again, this time along side the update 5 version in order to recreate the problem, however I was unsuccessfull.Somewhere in the installation procedureI must have messed up because visual studio could no longer find the compiler. I am sorry to say that I did pursue this issue further butinstead I removed all versions and installed update 5. This resolved my initial problem.

Lars