How to import a DLL into a Microsoft Visual Studio Fortran Project?

[Jesse_B_1]

Hello,

I am having problems importing a DLL into my current Fortran project. The DLL file I am trying to import, fdlltest.dll, has the following functions defined when I do dumpbin /exports:

C:\temp>dumpbin /exports fdlltest.dll
Microsoft (R) COFF/PE Dumper Version 12.00.40629.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file fdlltest.dll

File Type: DLL

  Section contains the following exports for fdlltest.dll

    00000000 characteristics
    560ED478 time date stamp Fri Oct 02 14:01:12 2015
        0.00 version
           1 ordinal base
           3 number of functions
           3 number of names

    ordinal hint RVA      name

          1    0 00001000 add2i
          2    1 00001010 add2r
          3    2 00001040 simpson

  Summary

        1000 .data
        1000 .rdata
        1000 .reloc
        1000 .rsrc
        1000 .text

Next, I need to know step-by-step how to import the add2i, add2r, and simpson functions from this DLL located in C:\temp into my current Fortran project. I do not want examples with *.lib, since the actual DLL I want to use once I get past this example does not have a companion *.lib. This is my Fortran code which is supposed to generate an EXE that is linked to the DLL file:

program fdllrun
 implicit none
INTERFACE
 INTEGER FUNCTION add2i(a,b) 
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"add2i" :: add2i
!DEC$ ATTRIBUTES REFERENCE::a, b
  INTEGER, intent(in), value:: a, b
 END FUNCTION add2i
 
 REAL FUNCTION add2r(a,b)
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"add2r" :: add2r
!DEC$ ATTRIBUTES REFERENCE::a, b
  REAL, intent(in), value:: a, b
 END FUNCTION add2r

 REAL FUNCTION simpson(f, a, b, n) 
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"simpson" :: simpson
!DEC$ ATTRIBUTES REFERENCE::f, a, b, n
  EXTERNAL f
  real, intent(in), value ::  a, b
  integer, intent(in), value :: n
 END FUNCTION simpson
END INTERFACE 

 ! Variables
 INTEGER :: i1, i2, ians
 i1=1
 i2=2

 ! Body of fdllrun
 ians = add2i(i1, i2)
 print '(I3)', ians

end program fdllrun

I tried to right click on my project and do Add -> Existing Item, then browse to the DLL file located in C:\temp, then Build All. It does not work. The errors I get when I try to compile are:

Error 1  error LNK2019: unresolved external symbol __imp_add2i referenced in function _MAIN__ fdllrun.obj 
Error 2  fatal error LNK1120: 1 unresolved externals Release\fdllrun.exe 
 

[IanH]

There are two mechanisms for an exe to link to a DLL - load time linking (happens automatically when the executable is loaded) and run time linking (happens until the control of specific code in the executable).

(I lie a bit - there is also a third mechanism - delay load linking - a hybrid of those two, but I am not familiar with it, so, like all things I am mostly ignorant of, I just pretend it doesn't exist.)

Which of those two mechanisms do you want?

To do run time linking you use the LoadLibrary and GetProcAddress Win32 API's (or some wrapper around them) to load the library (by name0 and get the relevant procedure address (by name or ordinal) - storing the procedure address in a procedure or integer pointer, and invoking it through that.  Fortran examples of the use of those API's should be relatively easy to discover.

To do load time linking (which is what I guess you want to do, given the interface blocks), at the time you build your executable you tell the linker that particular procedures are in a particular DLL.  You do that by providing the linker with an import library... i.e. a lib file.  Without such a library, the linker has no idea where the implementation of that procedure lives, so you get the error message you see.  If you want to use this mechanism and don't have an import library, then you need to make or get one.

You can make an import library by hand by writing a module definition file or by compiling and linking a pretend DLL - see https://support.microsoft.com/en-us/kb/131313 for starters.  There are tools out there that will do this from the information in the DLL, given certain assumptions, for you - I think I've seen such a tool in the mingw distribution of gcc.

[JVanB]

The tool is called dlltool.exe and there is an example at https://cygwin.com/cygwin-ug-net/dll.html .

Fleshing out the current code for this example, we start with foo.f90

MODULE M
   implicit none
   CONTAINS
 INTEGER FUNCTION add2i(a,b) 
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS:"add2i" :: add2i
!DEC$ ATTRIBUTES REFERENCE::a, b
  INTEGER, intent(in), value:: a, b
  add2i = a+b
 END FUNCTION add2i
 
 REAL FUNCTION add2r(a,b)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS:"add2r" :: add2r
!DEC$ ATTRIBUTES REFERENCE::a, b
  REAL, intent(in), value:: a, b
  add2r = a+b
 END FUNCTION add2r

 REAL FUNCTION simpson(f, a, b, n) 
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS:"simpson" :: simpson
!DEC$ ATTRIBUTES REFERENCE::f, a, b, n
  EXTERNAL f
  real f
  real, intent(in), value ::  a, b
  integer, intent(in), value :: n
  real h
  integer i
  h = (b-a)/2
  simpson = (h/3)*(f(a)+4*sum([(f(a+i*h),i=1,n-1,2)])+ &
    2*sum([(f(a+i*h),i=2,n-2,2)])+f(b))
 END FUNCTION simpson
END MODULE M

Now we compile it with ifort /nologo /dll foo.f90 . Then we delete the foo.lib, foo.exp, and foo.obj files, just so that there is nothing in our hands, nothing up our sleeves. Now we need a *.DEF file, in this case foo.def is

EXPORTS
add2i
add2r
simpson

Then we use dlltool.exe to make a *.a file

C:\>dlltool --def foo.def --dllname foo.dll --output-lib foo.a

And now we are ready to link with that *.a file:

C:/ifort /nologo fdllrun.f90 foo.a

Oh yeah, we also needed an fdllrunf90 file

program fdllrun
 implicit none
INTERFACE
 INTEGER FUNCTION add2i(a,b)
  implicit none
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"add2i" :: add2i
!DEC$ ATTRIBUTES REFERENCE::a, b
  INTEGER, intent(in), value:: a, b
 END FUNCTION add2i
 
 REAL FUNCTION add2r(a,b)
  implicit none
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"add2r" :: add2r
!DEC$ ATTRIBUTES REFERENCE::a, b
  REAL, intent(in), value:: a, b
 END FUNCTION add2r

 REAL FUNCTION simpson(f, a, b, n) 
  implicit none
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"simpson" :: simpson
!DEC$ ATTRIBUTES REFERENCE::f, a, b, n
  EXTERNAL f
  real f
  real, intent(in), value ::  a, b
  integer, intent(in), value :: n
 END FUNCTION simpson
END INTERFACE 

 ! Variables
 INTEGER :: i1, i2, ians
 i1=1
 i2=2

 ! Body of fdllrun
 ians = add2i(i1, i2)
 print '(I3)', ians

end program fdllrun

The output is 3, which is hopefully what you expected.

[Jesse_B_1]

Thank you Repeat Offender, for your detailed response. I got all the way up to where I need to use the command line for

C:/ifort /nologo fdllrun.f90 foo.a

However, my Developer Command Prompt for VS2013 says ifort is not a recognized command or program. Are command line solution builds done somewhere else?

[IanH]

That's the Visual Studio only command prompt (hence it has no idea about Fortran).  The command prompts for the Fortran compiler are accessible under the Intel Parallel Studio > Compilers and Libraries (or similar, depending on version) start menu items.

[Jesse_B_1]

Ok, I just gave it a try, I got:

C:\..>ifort /nologo fdllrun.f90 foo.a
fdllrun.obj : error LNK2019: unresolved external symbol __imp_add2i referenced 
in function MAIN__
fdllrun.exe : fatal error LNK1120: 1 unresolved externals

The solution did sound nice, but it did not work. I tried with both the 32 bit and 64 bit Intel Compiler command prompt. Any ideas what I may be doing wrong?

[mecej4]

If you are more comfortable working in Visual Studio, after you have built foo.a rename it as FOO.LIB and add that import library file to your project in the usual way.

This newly built FOO.LIB is the companion *.lib that you wrote about: "...since the actual DLL I want to use once I get past this example does not have a companion *.lib".

[Jesse_B_1]

Ok, so after renaming foo.a to foo.lib, where do I put it when I Add Existing Item? I tried both foo.lib alone, as well as it along with fdlltest.dll and placed them beneath the "fdllrun" project tree. Same errors, all to no avail.

[JVanB]

Well, it worked for me. I used the latest ifort, along with the dlltool.exe that came with gfortran 5.2, both 64-bit. I tried 32-bit ifort and apparently 32-bit dlltool.exe and I got the same error that you did. Here is my CMD.EXE session, given foo.f90, foo.def, and fdllrun.f90 as in Quote #3

C:\New folder>dir
 Volume in drive C is Windows
 Volume Serial Number is 58F5-A85A

 Directory of C:\New folder

10/02/2015  05:35 PM    <DIR>          .
10/02/2015  05:35 PM    <DIR>          ..
10/02/2015  03:39 PM               854 fdllrun.f90
10/02/2015  03:37 PM                32 foo.def
10/02/2015  03:32 PM               821 foo.f90
               3 File(s)          1,707 bytes
               2 Dir(s)  48,220,049,408 bytes free

C:\New folder>ifort /nologo /dll foo.f90
   Creating library foo.lib and object foo.exp

C:\New folder>del foo.lib foo.exp foo.obj

C:\New folder>dir
 Volume in drive C is Windows
 Volume Serial Number is 58F5-A85A

 Directory of C:\New folder

10/02/2015  05:36 PM    <DIR>          .
10/02/2015  05:36 PM    <DIR>          ..
10/02/2015  03:39 PM               854 fdllrun.f90
10/02/2015  03:37 PM                32 foo.def
10/02/2015  05:35 PM             7,680 foo.dll
10/02/2015  03:32 PM               821 foo.f90
10/02/2015  05:35 PM             1,500 m.mod
               5 File(s)         10,887 bytes
               2 Dir(s)  48,220,037,120 bytes free

C:\New folder>dlltool --def foo.def --dllname foo.dll --output-lib foo.a

C:\New folder>ifort /nologo fdllrun.f90 foo.a

C:\New folder>fdllrun
  3

[JVanB]

OK, I found out what went wrong with the 32-bit build. In that case, dlltool.exe prepends underscores to the names but ifort, since you are using the ALIAS attribute, does not. It might be possible to fix this by using BIND(C) instead of !DEC$ ATTRIBUTES, or by adding the DECORATE attribute (I didn't check) but certainly putting underscores in there works. Here is the file that worked for the 32-bit build, fdllrun32.f90

program fdllrun
 implicit none
INTERFACE
 INTEGER FUNCTION add2i(a,b)
  implicit none
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"_add2i" :: add2i
!DEC$ ATTRIBUTES REFERENCE::a, b
  INTEGER, intent(in), value:: a, b
 END FUNCTION add2i
 
 REAL FUNCTION add2r(a,b)
  implicit none
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"_add2r" :: add2r
!DEC$ ATTRIBUTES REFERENCE::a, b
  REAL, intent(in), value:: a, b
 END FUNCTION add2r

 REAL FUNCTION simpson(f, a, b, n) 
  implicit none
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"_simpson" :: simpson
!DEC$ ATTRIBUTES REFERENCE::f, a, b, n
  EXTERNAL f
  real f
  real, intent(in), value ::  a, b
  integer, intent(in), value :: n
 END FUNCTION simpson
END INTERFACE 

 ! Variables
 INTEGER :: i1, i2, ians
 i1=1
 i2=2

 ! Body of fdllrun
 ians = add2i(i1, i2)
 print '(I3)', ians

end program fdllrun

Now I could compile with ifort /nologo fdllrun32.f90 foo.a, and the resulting fdllrun32.exe produces the output 3, as before. I just checked and the DECORATE attribute works in your case, so your best option, rather than maintaining a separate function ALIAS for 32- and 64-bit versions, is to add the DECORATE attribute to each function name in each interface body in the calling program unit.

[IanH]

I don't think you actually need that dlltool to do this - the windows system linker (moonlighting as lib.exe) can generate import libraries from def files (lib.exe /def:foo.def /out:foo.lib).  You will have the same extraneous underscore issue on x86 though.  The workaround for that is just to compile the dummy dll that you had in #3... delete the resulting dll and just use its lib file.

For the OP - you do need to be consistent in your bitness between your DLL and your EXE.

[Jesse_B_1]

Thank you Repeat Offender, your clarifications were helpful! I did a little more reading on the DECORATE flag, and put this into my Visual Studio program making the DLL file:

!DEC$ IF DEFINED(_WIN32) 
 !DEC$ ATTRIBUTES DECORATE, DLLEXPORT, ALIAS:"add2i" :: add2i 
!DEC$ ELSE 
 !DEC$ ATTRIBUTES DECORATE, DLLEXPORT, ALIAS:"add2i_" :: add2i 
!DEC$ END IF 
!DEC$ ATTRIBUTES REFERENCE :: x, y

I then went to doing the same command line commands that you suggested earlier with dlltool to make *.a:

C:\...>dlltool --def fdlltest.def --dllname fdlltest.dll --output-lib fdlltest.a

Next, I did something fairly similar with DECORATE in the main Visual Studio program using the DLL file:

!DEC$ ATTRIBUTES DECORATE, DLLIMPORT, ALIAS:"add2i" :: add2i
!DEC$ ATTRIBUTES REFERENCE::a, b

I next tried to use mesej4's method for creating a *.lib file and added it to the main Visual Studio program (inside the fdllrun tree) and attempted to build within Visual Studio, but that did not work. mesej4, perhaps you could clarify how you set up Visual Studio and the loading of files that got it working for you within the GUI?

So I went back to the command line method suggested earlier by Repeat Offender:

C:\...>ifort /nologo fdllrun.f90 fdlltest.a

It then built without any errors! Next, I ran it:

C:\...>fdllrun.exe
3

So it is now working with this example!

Hopefully the last thing, but how do you choose a 32 bit compilation in Intel Fortran Visual Studio? When I go to Configuration Manager and try to change the Platform from Win32, my only option for New platform is "x64". I need to be able to select 32 bit as the actual DLL files I'm trying to use were compiled in 32 bit. I guess the only way to choose between one or the other is with Intel Compiler version you launch, IA-32 or Intel 64?

Thanks again for the help.

[IanH]

Win32 is the 32 bit configuration (also known as x86 or IA-32).

[JVanB · Accepted solution]

I got this to work in Visual Studio. First, in some neutral directory, from the 32-bit ifort command prompt, I compiled foo.f90 to a DLL with

ifort /nologo /dll foo.f90

and then with the command

lib /def:foo.def /out:foo.lib

made the foo.lib file. Note that I used the foo.f90 from Quote #3; the modifications in Quote #12 are wrong because, firstly, the reason for the DECORATE attribute is to avoid the conditional compilation with !DEC$ IF DEFINED(_WIN32), so you don't need them both. Secondly, you don't need DECORATE here unless the calling convention of the DLL is set to STDCALL. Third, the ALIAS of 'add2i_' is wrong anyway. Just use dumpbin /exports to see what the symbols from your target DLL look like and see if what this test DLL exports look similar. Can you disclose as much as one symbol exported by the target DLL as seen by dumpbin /exports?

Ok, now start Visual Studio, start a new project, and under Intel(R) Visual Fortran, Console Application, select Empty Project, Name: fdllrun, check Create directory for solution, then OK. Now open a couple of Windows explorers <WINDOWS>+E <WINDOWS>+<LEFT> <WINDOWS>+E <WINDOWS>+<RIGHT> and navigate to where your original fdllrun.f90 file as you modified it with DECORATE is and copy it over to D:\blahblahblah\fdllrun\fdllrun . Then you should be able to add it as an existing source file.

Then you have to go to Project -> fdllrun properties -> Linker -> general, and set the directory where that foo.lib that you made resides as an Additional Library Directory. Also under Linker -> Input, set foo.lib as an additional dependency. Then select OK.

Then you can do build -> rebuild solution and it should build but not run because that DLL isn't on your path. To fix this, go back to your two copies of Windows Explorer and copy foo.lib from where it is to D:\blahblahblah\fdllrun\fdllrun, and also copy foo.dll to D:\blahblahblah\fdllrun\fdllrun\release (I assumed a release build here; maybe you need debug instead of release?) Then you can go back to Project -> fdllrun properties -> Linker -> general -> Additional Library Directories and change that directory to D:\blahblahblah\fdllrun\fdllrun\release (or debug as the case may be).

Now you can do build -> rebuild all, and it should build, then debug -> start without debugging, and it should run to completion. If I can figure out how to do this in Visual Studio, anyone can do it.

[JVanB]

Oops, that last additional library directory should have been D:\blahblahblah\fdllrun\fdllrun, the directory where you put foo.lib. You can't put foo.lib in the release or debug directory because is then gets trashed by Rebuild All.

[Jesse_B_1]

Thanks Repeat Offender, your answers were helpful and enabled me to successfully compile and run in the Visual Studio environment. Everything is now working in these tests.

[Jesse_B_1]

I should add one more thing. I had to tweak some things to get C++ DLL imports to work. But the same concepts with making lib and def files, then moving the lib and dll file into the same directory as the code and changing the linker settings still applied.

Here was the dumpbin output of my C++ DLL (I made sure to use extern "C" within the C++ code):

c:\...>dumpbin /exports cdlltest.dll
Microsoft (R) COFF/PE Dumper Version 12.00.40629.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file cdlltest.dll

File Type: DLL

  Section contains the following exports for cdlltest.dll

    00000000 characteristics
    560DA48A time date stamp Thu Oct 01 16:24:26 2015
        0.00 version
           1 ordinal base
           5 number of functions
           5 number of names

    ordinal hint RVA      name

          1    0 000010A0 add
          2    1 000010D0 divide
          3    2 00001140 modulus
          4    3 000010C0 multiply
          5    4 000010B0 subtract

  Summary

        1000 .data
        1000 .rdata
        1000 .reloc
        1000 .rsrc
        1000 .text

Here is how I had to modify the Fortran code:

program cdllrun
 USE, intrinsic :: ISO_C_BINDING, only: C_INT, C_DOUBLE
 implicit none
INTERFACE
 SUBROUTINE modulus(a, b, ans) BIND(C, name='modulus')
  import
  implicit none
! !DEC$ ATTRIBUTES DECORATE, DLLIMPORT, ALIAS:"modulus" :: modulus
! !DEC$ ATTRIBUTES REFERENCE::a, b
  INTEGER(KIND=C_INT), intent(in), value:: a, b
  INTEGER(KIND=C_INT), intent(out) :: ans
 END SUBROUTINE modulus

 REAL(KIND=C_DOUBLE) FUNCTION add(a, b) BIND(C, name='add')
  import
  implicit none
! !DEC$ ATTRIBUTES DECORATE, DLLIMPORT, ALIAS:"add" :: add
! !DEC$ ATTRIBUTES REFERENCE::a, b
  REAL(KIND=C_DOUBLE), intent(in), value:: a, b
 END FUNCTION add
 
 REAL(KIND=C_DOUBLE) FUNCTION subtract(a, b) BIND(C, name='subtract')
  import
  implicit none
! !DEC$ ATTRIBUTES DECORATE, DLLIMPORT, ALIAS:"subtract" :: subtract
! !DEC$ ATTRIBUTES REFERENCE::a, b
  REAL(KIND=C_DOUBLE), intent(in), value:: a, b
 END FUNCTION subtract

 REAL(KIND=C_DOUBLE) FUNCTION multiply(a, b) BIND(C, name='multiply')
  import
  implicit none
! !DEC$ ATTRIBUTES DECORATE, DLLIMPORT, ALIAS:"multiply" :: multiply
! !DEC$ ATTRIBUTES REFERENCE::a, b
  REAL(KIND=C_DOUBLE), intent(in), value:: a, b
 END FUNCTION multiply

 REAL(KIND=C_DOUBLE) FUNCTION divide(a, b) BIND(C, name='divide')
  import
  implicit none
! !DEC$ ATTRIBUTES DECORATE, DLLIMPORT, ALIAS:"divide" :: divide
! !DEC$ ATTRIBUTES REFERENCE::a, b
  REAL(KIND=C_DOUBLE), intent(in), value:: a, b
 END FUNCTION divide
 
END INTERFACE 

 ! Variables
 INTEGER(KIND=C_INT) :: i1, i2, ians
 i1=65
 i2=8
 
 ! Body of cdllrun
 CALL modulus(i1, i2, ians)
 print '(I3)', ians

end program cdllrun

The answer was 1. I followed the thread here to help come up with the right code:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/278937

[JVanB]

Good to hear that things are going well, and also that you changed over to BIND(C) instead of !DEC$ ATTRIBUTES to handle interfacing issues. The only reason I couched my replies in terms of !DEC$ ATTRIBUTES was on the off-chance that the DLL you were trying to interface to was itself written in Intel Fortran, in which case it might prove awkward to match up assumed-shape arguments, for example, with BIND(C). In just about all other cases (VARYING being one exception) BIND(C) is much more straightforward and transportable.