- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
This message is mainly for Steve Lionel. A couple of years ago, I saw some information about exporting module datain a DLL so that it could be used by the main program and by other DLLs. I can now find information about doing that for data in COMMON blocks, but I can't find the reference for how to do it with data in modules any more. Can you please point out where to find that information?
Thanks
Steve
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Steve. It ought to work in a similar fashion to COMMON - use a !DEC$ ATTRIBUTES DLLEXPORT directive that names the variable when compiling the module. The export should be turned into an import when you use the module. You will get warnings from the linker if you use the module elsewhere in the DLL, but those can be ignored.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Steve,
Is there any example piece of code available? The example that I want to export consists of many nested structures, and I am looking to see what to do. Is it possible to export only the highest level structure name, and have the rest mapped automatically?
Thanks
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To Steve Lionel,
Do you name the module variable in the DLLEXPORT statement, or the module itself. For common blocks, you name the module itself.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For COMMON blocks, you name the common.For variables, you name the variables. Simple example:
Code:
module foo integer bar !dec$ attributes dllexport :: bar end module foo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Steve,
This is not working for us. Our basic requirement is to have a DLL holding data, with that data shared between the main program and many other DLLs. For example, I set up a test with a main program and two DLLs. DLL 1 was a data store, and DLL 2 contained a subroutine. The technique that you described seems to be able to allow the main program to use DLL 1's data, but I cannot get DLL 2 to access the data. If I use "foo" in DLL 2, it creates an independent data store. If I modify the version of the module in DLL 2 to havea DLL import statement, it declares a double definition. If I declare "bar" as a local in the DLL 2 subroutine and add a DLL import statement for it, it is generated as a local and the import statement is ignored. Somehow I need to import into DLL 2 what is exported from DLL 1. How do I talk it into allowing DLL 2 subroutines to share the data?
Thanks
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't quite understand what you did here, but I don't have time right now to work up a complete example. I vaguely remember some issues in this area with CVF. If you have the problem with Intel Visual Fortran, feel free to send it to Intel Premier Support and we can take a look.

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