Trouble calling the IMSL libraries from a DLL

[danielmclaury]

I am trying to create a FORTRAN DLL that calls the IMSL libraries. Toy code:

[fortran]module testmod

  use CBRT_int
  
  implicit none
  
  include 'link_fnl_static.h'   ! links IMSL library

  contains

  subroutine helloworld()
    !DEC$ ATTRIBUTES DLLEXPORT::helloworld
    !DEC$ ATTRIBUTES ALIAS:'_helloworld' :: helloworld
    
    open(unit=10, file="C:\\hello.txt")
    write(10, *) "Hello World!"
    close(10)
  end subroutine helloworld    
  
  subroutine f()
    real :: x
    
    x = CBRT(10.0)
    write (*, *) x
  end subroutine f  

end module[/fortran]

This compiles just fine, but when I try to call the helloworld() routine, I get an "invalid access to memory location" error, the memory location in question being 0x00000000. If I comment out the line x = CBRT(10.0), I can run the helloworld() routine just fine. (Note in particular that helloworld() does not call f() at all, so the problem happens when I'm trying to load the DLL.) If I convert this into a standalone program, it gives me no trouble, and calls the IMSL routine correctly and returns the right answer.

Has anyone got any idea what's going on here? I don't even see any way of debugging this.

Thanks in advance.

EDIT: This code runs fine on a colleague's computer, so it must be some kind of configuration issue. We've checked basically all the system-wide configuration and can't find anything wrong, though. Any pointers as to where we might look would be appreciated. (Intel Fortran 11.0.061, Visual Studio 2005, Windows XP)

[danielmclaury]

Apparently this is a compiler issue -- upgrading to a slightly newer version makes it go away.

[Steven_L_Intel1]

Unclear... If you are building a DLL, you really should link to the DLL version of IMSL as otherwise you have duplicate libraries. In particular, you may have duplicate OpenMP libraries that can be a big problem. I'm not aware of any compiler issue that affects this, but if it works for you now, great.

[danielmclaury]

So, as it turns out, I seem to have spoken too soon -- despite my DLL working yesterday, the same DLL file no longer works today, instead giving the errors it was before. (I didn't recompile -- it was literally the same file that was working yesterday.) All I've done is reboot the computer! The upgrade itself must have somehow temporarily modified something about the way DLLs were loaded -- maybe by clearing out some kind of cached information?

The code we had before had linked to the static libraries, and changing to the dynamic libraries hadn't fixed anything before. I'll try it now, and see what I can do about OpenMP too -- is there any way to trace an error like this? Since the DLL never actually fully loads, most debugging information just seems to tell me that the call to the DLL is what failed.

Also, what is the correct way to load the shared libraries? Currently I have

[fortran]include 'link_fnl_shared.h'   ! links IMSL library[/fortran]

This should show all my compiler flags and such.

[plain]Compiling with Intel Visual Fortran 11.1.070 [IA-32]...
ifort /nologo /debug:full /Od /Qparallel /gen-interfaces /warn:interfaces /iface:cref /module:"Debug" /object:"Debug" /traceback /check:bounds /libs:dll /threads /dbglibs /c /Qvc8 /Qlocation,link,"c:Program FilesMicrosoft Visual Studio 8VCbin" "C:DataVisual Studio 2005ProjectsDll1Dll1Source1.F90"
Compiling manifest to resources...
rc.exe /fo "C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.dll.embed.manifest.res" "C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.dll.embed.manifest.rc"
Linking...
Link /OUT:"DebugDll1.dll" /NOLOGO /MANIFEST /MANIFESTFILE:"C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.dll.intermediate.manifest" /DEBUG /PDB:"C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.lib" /DLL "DebugSource1.obj" "C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.dll.embed.manifest.res"
Link: executing 'link'
LINK : DebugDll1.dll not found or not built by the last incremental link; performing full link
 Creating library C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.lib and object C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.exp

Embedding manifest...
mt.exe /nologo /outputresource:"C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.dll;#2" /manifest "C:DataVisual Studio 2005ProjectsDll1Dll1DebugDll1.dll.intermediate.manifest"
[/plain]

Any ideas?

[Steven_L_Intel1]

I've tried to reproduce the problem but could not. Can you attach a ZIP of both the DLL project and the executable that calls this DLL?

[danielmclaury]

Attached. Thanks for helping me out on this!

[Steven_L_Intel1]

I can't reproduce the problem with your files. I had to make some adjustments to the C# program to get it to run on my x64 system, but that should not change whether an access violation was seen. Does it help if you build a Release configuration of the DLL?

[mecej4]

I do not have your versions of VS and IFort, and I do not know what version of IMSL you used.

I compiled and ran the example from the command line with no errors, using IFort 12.0.4.

[bash]s:> ifort /LD /Qimsl Source1.F90 /FeDll1.dll

s:> csc ..ConsoleApplication1Program.cs

s:> Program.exe
[/bash]

Therefore, the problem, if any, is not with the source files but with the versions that you use or some other aspects of your system.

[danielmclaury]

Okay, I have it working again. It looks like the issue wasn't with the IMSL libraries per se but with some other libraries that they, in turn, linked to. Apparently I still had some DLLs floating around from the 11.0.061 install -- I still don't know *where* -- and the program's choice of where to load from was environment-dependent. I uninstalled everything, manually deleted the Intel and VNI directory trees, and then reinstalled from scratch, and things seem to be working better now.

Thanks for the help -- I don't think I would have realized this as quickly if I hadn't tried building from the command line to get better control over the compiler flags. Things worked there (using rundll32) that didn't work in Visual Studio, which was a pretty clear hint as to what was happening.