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

Simple DLL question

mattsdad
Beginner
618 Views

I have an example program that compiles and links just fine. It has one module with three program that I want to make into a DLL. I made an interface module that defines the interface to these three subroutines. I set up two Visual Studio projects that could only see the part that they need. One generates a DLL file just fine, but the one the the driver and interface modulecannot find the subroutines. What do I need to add to the Visual Studio properties or code to find and open the DLL?

0 Kudos
8 Replies
Steven_L_Intel1
Employee
618 Views
Assuming that you have the DLL project and executable project in the same solution, right click on the executable project, select Dependencies, and check the box for the DLL project to make it a dependent of the executable.

If the executable project also needs to see the modules from the DLL, add the DLL project's output folder (Debug or Release) to the "Additional INCLUDE paths" list in the executable project's Fortran property page.
0 Kudos
mattsdad
Beginner
618 Views

Thanks Steve,

I used the DUMPBIN utility to look at the symbols. It turned out that the symbols in the DLL were generated with a module name preface and the procedure that was using the DLL didn't expect the module name preface. I did have the interface declarations in a module with the same name, but that appearantly didn't pass through.

Is there a simple way to get the module with the interface declarations to associate the module name with the subroutines?

Mattsdad

0 Kudos
Steven_L_Intel1
Employee
618 Views
Sure - USE the module. If the module had the DLLEXPORT directives, this also turns into DLLIMPORT when you USE it. It sounds as if you were calling the module procedures without a USE of the module.
0 Kudos
mattsdad
Beginner
618 Views

I thought I did that like this:

MODULE

My_DLL

CONTAINS

SUBROUTINE XXX()

!DEC$ ATTRIBUTES DLLEXPORT :: XXX

! ...

END SUBROUTINE XXX()

END MODULE

My_DLL

PROGRAM

Main()

USE My_DLL

! ...

CALL XXX()

! ...

END

PROGRAM Main

The Main procedure compiled and linked just fine whenMy_DLL was in the same project, compiled together with the module.

The project with the main routine was modified to add an interface module when My_DLL was separated to another project.

MODULE

My_DLL

INTERFACE

SUBROUTINE XXX()

!DEC$ ATTRIBUTES DLLIMPORT :: XXX

END SUBROUTINE XXX()

INTERFACE

END MODULE

My_DLL

So what do you mean by "USE the module"?

0 Kudos
Steven_L_Intel1
Employee
618 Views
No - that's not correct. When you created a separate module with the INTERFACE, that is declaring an "external procedure" which is not the same as the module procedure.

What I meant was to USE MY_DLL with it seeing the .mod from the build of the DLL project, not a different one in the executable project. That way it will see the correct definition.
0 Kudos
mattsdad
Beginner
618 Views
Is it possible to make the data from the module in the DLL visible in the main program?
0 Kudos
Steven_L_Intel1
Employee
618 Views

Yes - just add a DLLEXPORT directive for the module-level variable and it will be "imported" when the module is USEd. There is an example of this provided in sample DLL_Shared_Data.

Steve

0 Kudos
mattsdad
Beginner
618 Views

Thanks

Mattsdad

0 Kudos
Reply