- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am trying to export functions contained in a module in a DLL, and then, of course, import these functions from another program. I am not able to do it. I have followed the "standard" procedure with the !DEC$ ATTRIBUTE :: DLL EXPORT in the function declaration I want to export. I have included the .lib in the project and the Dll has been moved in System32. and the interface statement in the calling program. But it does not work, It fails at linker time. does anybody know how to do it ?
Thanks luca
I am trying to export functions contained in a module in a DLL, and then, of course, import these functions from another program. I am not able to do it. I have followed the "standard" procedure with the !DEC$ ATTRIBUTE :: DLL EXPORT in the function declaration I want to export. I have included the .lib in the project and the Dll has been moved in System32. and the interface statement in the calling program. But it does not work, It fails at linker time. does anybody know how to do it ?
Thanks luca
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This should work without difficulty, especially if you are using the dll routines in a fortran routine. You mention the interface statement in the calling program. I'm not sure why? If the routines are in a module, and the caller is f90, use USE.
This works just fine (absent any typos, and assuming the .lib file is available, I use project dependancies for this, but adding the .lib file will work). Note that the module decorated name is exported from the DLL, in this case A_mp_FOO@4 (I think). Also, if you are using generic procedures, you can export each of the specific procedures, and use the generic in the caller - the compiler will resolve the calls to the specifics at compile time (if you USE the module) and the linker will resolve the specifics to the exported routines at link time.
hth,
John
This should work without difficulty, especially if you are using the dll routines in a fortran routine. You mention the interface statement in the calling program. I'm not sure why? If the routines are in a module, and the caller is f90, use USE.
! a.f90 module a contains function foo(i) result !dec$ attributes dllexport :: foo impliciit none integer, intent(in) :: i integer :: r r = i + 1 end subroutine foo end module a ! b.f90 subroutine bar() use a implicit none ! ... some_int = foo(some_other_int) end subroutine bar
This works just fine (absent any typos, and assuming the .lib file is available, I use project dependancies for this, but adding the .lib file will work). Note that the module decorated name is exported from the DLL, in this case A_mp_FOO@4 (I think). Also, if you are using generic procedures, you can export each of the specific procedures, and use the generic in the caller - the compiler will resolve the calls to the specifics at compile time (if you USE the module) and the linker will resolve the specifics to the exported routines at link time.
hth,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problem is that you can't reliably USE this module in the program that wants to call the module routine. This is an open issue that's on my list to look at.
Steve
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'll certainly take your word for it, Steve. :-)
But I know I've done this in the past and one of our models exports module routines in just this way in a number of DLLs. We had to work through some issues in earlier versions of CVF, but nothing I can recall recently.
Can you elaborate on your comment on not being able reliably USE the module in the calling program unit?
Thanks,
John
But I know I've done this in the past and one of our models exports module routines in just this way in a number of DLLs. We had to work through some issues in earlier versions of CVF, but nothing I can recall recently.
Can you elaborate on your comment on not being able reliably USE the module in the calling program unit?
Thanks,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks John and Steve,
unfortumately I finding what Steve has written, it does not let me use the USE statment.
Thanks anyway,
Luca
unfortumately I finding what Steve has written, it does not let me use the USE statment.
Thanks anyway,
Luca
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm trying to comment on John's post, assuming the forum software cooperates.
I agree with your claim if using CVF 6.5. Since CVF 6.6, however, you'll get a warning:
Warning: DEC$ ATTRIBUTES DLLIMPORT is ignored for non-external procedure. [FOO]
The 'DLLIMPORT' isn't my typo! FOO will export and you can call it within its dll assuming you USE a.
Bogus warnings seem to be a new feature of CVF 6.6.
Ciao,
Gerry T.
I'm trying to comment on John's post, assuming the forum software cooperates.
I agree with your claim if using CVF 6.5. Since CVF 6.6, however, you'll get a warning:
Warning: DEC$ ATTRIBUTES DLLIMPORT is ignored for non-external procedure. [FOO]
The 'DLLIMPORT' isn't my typo! FOO will export and you can call it within its dll assuming you USE a.
Bogus warnings seem to be a new feature of CVF 6.6.
Ciao,
Gerry T.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This change was made in 6.5A. The warning isn't bogus, but the wording needs improvement. We understand the need for a good solution here and are working towards that. The best I can suggest for now is INTERFACE blocks that have the proper ALIAS specified.
Steve
Steve

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