Exporting COMMON block in a DLL
Arjen Markus
I am facing the following problem:
I use the Compaq Visual Fortran compiler on Windows to create a DLL
(the
routines are exported via a .def file, so that I do not have to use
compiler
directives). Unfortunately, I also need to export a COMMON block.
I naively tried to do that in a similar way as the routines (by
specifying
its name with a leading underscore) in the .def file, but the linker
did
not fall for that.
Does anyone know how to export such COMMON blocks?
Regards,
Arjen
Colin Watters
"Arjen Markus" <arjen....@wldelft.nl> wrote in message
news:2c1ce147-91a4-4007...@i20g2000prf.googlegroups.com...
"Attributes DLLEXPORT" directive in the source. See help, index, type in
"dllexport", and select entry "for common blocks".
--
Qolin
Email: my qname at domain dot com
Domain: qomputing
Arjen Markus
wrote:
> "Arjen Markus" <arjen.mar...@wldelft.nl> wrote in message
>
> - Tekst uit oorspronkelijk bericht weergeven -
Right, so I have to use the attributes directive. I had hoped
to avoid that, but so be it.
Thanks,
Arjen
Steve Lionel
<arjen....@wldelft.nl> wrote:
>Right, so I have to use the attributes directive. I had hoped
>to avoid that, but so be it.
You can avoid the directives for routines, but for data, the compiler needs to
know to do the extra level of indirection and thus it has to see a DLLIMPORT
directive. (If you USE a module that contains a DLLEXPORT, it is treated as
DLLIMPORT.)
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Colin Watters
news:lkg3o4lttgjmimuop...@4ax.com...
> On Thu, 29 Jan 2009 00:20:57 -0800 (PST), Arjen Markus
> <arjen....@wldelft.nl> wrote:
>
>
>>Right, so I have to use the attributes directive. I had hoped
>>to avoid that, but so be it.
>
> You can avoid the directives for routines, but for data, the compiler
> needs to
> know to do the extra level of indirection and thus it has to see a
> DLLIMPORT
> directive. (If you USE a module that contains a DLLEXPORT, it is treated
> as
> DLLIMPORT.)
Steve
For DLLIMPORT I can understand this. But for DLLEXPORT I had assumed you
needed just one such directive in the source code of the dll, regardless of
how many routines declare a given common block. Am I wrong? If so, what
happens when routine A has a dllexport but routine B does not, when they
both declare block /ccc/ ? (A and B are in the dll that exports the block).
Reason for the dictinction is the preference of users like Arjen, who may
appreciate 'hiding' such directives in a little-used out-of-the-way piece of
source that gets included in the dll.
Steve Lionel
<qolin.see...@nowhere.co.uk> wrote:
>> You can avoid the directives for routines, but for data, the compiler
>> needs to
>> know to do the extra level of indirection and thus it has to see a
>> DLLIMPORT
>> directive. (If you USE a module that contains a DLLEXPORT, it is treated
>> as
>> DLLIMPORT.)
>For DLLIMPORT I can understand this. But for DLLEXPORT I had assumed you
>needed just one such directive in the source code of the dll, regardless of
>how many routines declare a given common block. Am I wrong? If so, what
>happens when routine A has a dllexport but routine B does not, when they
>both declare block /ccc/ ? (A and B are in the dll that exports the block).
You need only one DLLEXPORT for a given symbol. If the COMMON is in a module,
do it there. Otherwise I'd probably create a BLOCK DATA subprogram, with an
EXTERNAL reference to it somewhere else, and put the DLLEXPORT in the BLOCK
DATA.
Extra DLLEXPORTs for the COMMON don't hurt.
The point of my post quoted above is that there is no substitute for a
DLLIMPORT directive when importing a variable or common block. A .DEF file
can be used when creating the DLL but not when referencing it.
My personal preference is for module variables over COMMON, but if you're
adapting existing code then COMMON is fine.