- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page