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

Sharing data between DLLS using modules

bbeyer
Novice
683 Views

I am having problems sharing data between 2 DLLS, using a module as shown in the sample. An unresolved external is generated for variable DESIGN when compiling DLL1. Any help would be appreciated, thanks.

PROGRAM rungrid

IMPLICIT NONE

INTERFACE

INTEGER*4 function grid(iStructIdIn)

!DEC$ ATTRIBUTES DLLIMPORT :: grid

!DEC$ ATTRIBUTES VALUE :: iStructIdin

INTEGER*4 iStructIdIn

END function

END INTERFACE

INTEGER*4 iStructId

INTEGER*4 lret

ISTRUCTID = 1

lret = grid(iStructId)

STOP

END

MODULE DESIGN_DATA

TYPE DESIGNDATA

REAL*8 :: A = 0.0D0

REAL*8 :: B = 0.0D0

END TYPE

TYPE(DESIGNDATA), SAVE :: DESIGN

!DEC$ ATTRIBUTES DLLEXPORT :: DESIGN

END MODULE DESIGN_DATA

integer*4 function grid(iStructIdIn)

!DEC$ ATTRIBUTES DLLEXPORT :: grid

!DEC$ ATTRIBUTES VALUE :: iStructIdin

USE DESIGN_DATA

IMPLICIT NONE

INTEGER*4 iStructIdIn ! -- Id of structure to design

INTEGER J, K

DESIGN.A = 1.25D0

CALL DLL1(J,K)

GRID = 12

RETURN

END

!DEC$ ATTRIBUTES DLLEXPORT::DLL1

!

USE DESIGN_DATA

!

IMPLICIT NONE

!

INTEGER I, J

REAL*8 A

!

A = DESIGN.A

I = 4

J = 5

!

RETURN

end subroutine DLL1

0 Kudos
5 Replies
Lorri_M_Intel
Employee
683 Views

When you compiled the module named DESIGN-DATA, there was an object file created.

Where was that linked in?

I'm not sure where the file delimiters are in your example, so I made up my own.

I put subroutine dll1 into its own dll, called "dll1" and linked the DESIGN-DATA object file into that same dll.

ifort /LD dll1.f90 design_data.obj

I put function grid into its own dll, called "dll2", and linked it against the dll1.lib created in the previous step

ifort /LD dll2.f90 dll1.lib

and it linked fine.

Finally, I linked your main program against the two .lib files, and it built successfully.

I think you were missing the design_data.obj That's where the data is actually declared. The mod files contain interfaces, derived-type declarations, etc. but not actual data. That's in the object file.

- Lorri

0 Kudos
Steven_L_Intel1
Employee
683 Views

It would be easier to help you if you would attach a ZIP of a solution and projects that showed the problem. You may not be linking it right.

Have you looked at the provided sample DLL_Shared_Data? This does what you're trying to do here.

0 Kudos
bbeyer
Novice
683 Views

I have attached a zip file of the project. This project is built on CVF 6.6B. I am not sure how to get the linking correct.

Thanks Steve and Lorri!

0 Kudos
Steven_L_Intel1
Employee
683 Views

Ah, CVF...

At minimum, you have a circular dependency in your projects. DLL1 uses module DESIGN_DATA in project MYDLL and references a variable declared there, and project MYDLL calls a routine in DLL1, so is dependent on DLL1 being built first. Can these two projects be combined? I haven't looked to see what further issues there are.

My general advice is that one DLL should define the shared data and not depend on any other DLL. If you are doing cross-process sharing of the data, you can link the shared data DLL with the RWS section attribute for .DATA. In CVF, there is a sample project that does this, I think it is called DLL2, but I don't like the way it is constructed and completely rewrote it for Intel Visual Fortran as DLL_Shared_Data.

0 Kudos
bbeyer
Novice
683 Views
Thanks Steve,your ideas worked. We made a separate DLL to define the shared data eliminating the circular reference and added the linker option "/section:.data,RWS" into this DLL and it works. Thanks again!
0 Kudos
Reply