Can you DLLEXPORT a derived type?

[Ranbir_Singh_Shoker]

I have a module in which is part of a DLL, in which there is a derived type definition. Can I use DLLEXPORT to export this type definition to be used in the main fortran exe? I have tried naively using

!DEC$ ATTRIBUTES DLLEXPORT :: MyType

but this doesn't seem to work. Or is the only way to accomplish this by defining the type in a standalone module which means this module has to be physically included in both the DLL and main project?

Thanks

Ranbir

[Steven_L_Intel1]

DLLEXPORT is for things the linker can see - routines, common blocks and variables; things with allocated storage. A derived type declaration is just information for the compiler, it is not an object. You will need to USE a module which defines the derived type in order to make it accessible.

The easy way to do this is to use the same .mod that was created when you built your DLL, which presumably has DLLEXPORT directives for the routines. The compiler will convert a DLLEXPORT in a module that is USEd into a DLLIMPORT, and the derived types and other declarations will be visible. The actual code for the exported routines is not in the .mod so you don't get duplication of routines.

[Ranbir_Singh_Shoker]

Thanks for that...I tried it and it works fine. I've also come across another problem. I use the module in which the type and its associated procedures are defined in other routines in the DLL in which they are defined. I also have that same moduleexporting all of its associated procedures. This leads to a link warning LNK4217 and LNK4049 in the DLL, which I guess comes about because as you say the DLLEXPORT gets converted to a DLLIMPORT even though the proceduresare local. Apart from the warning, is it safe to do this? If so, is there any way to suppress the warning?

[Steven_L_Intel1]

The warnings are harmless. You may be able to suppress them by adding "/ignore:4217 /ignore:4049" to the linker options.

[Ranbir_Singh_Shoker]

That works perfectly...thanks.

[Intel_C_Intel]

Steve, on a (sort of) related note, have you any idea why this doesn't work (it works ok in CVF)?

dll:

module Console4Module

type t_typevar
character(80) :: string = 'default string'
integer :: int1 = 1
integer :: int2 = 2
integer :: int3 = 3
end type t_typevar

type (t_typevar), parameter :: CONST_TYPEVAR = &
t_typevar('parameter string',100,200,300)
!DEC$ ATTRIBUTES DLLEXPORT::CONST_TYPEVAR

end module Console4Module


calling program:

program Console4

use Console4Module

implicit none

type (t_typevar) :: typevar

typevar = CONST_TYPEVAR ! Garbage

typevar%string = CONST_TYPEVAR%string ! OK
typevar%int1 = CONST_TYPEVAR%int1
typevar%int2 = CONST_TYPEVAR%int2
typevar%int3 = CONST_TYPEVAR%int3

end program Console4

[Steven_L_Intel1]

Looks like a bug. Please report it to Intel Premier Support.