Error: prPromoteSym : Illegal KIND & CLASS mix (?)

[John4]

Hi,

I have a structure defined in a dll (Dll1.dll), say:

module

dlltypes

type ABCTYPE

integer A integer B integer C end type ABCTYPE !DEC$ ATTRIBUTES DLLEXPORT::ABCTYPE

end module

dlltypes

and I am using it in another dll, say:

module

dllmod

!DEC$OBJCOMMENT LIB: "Dll1.lib" use dlltypes type(ABCTYPE) :: X, Y, Z contains type(ABCTYPE) function func1()

!DEC$ ATTRIBUTES DLLEXPORT::func1

X

= ABCTYPE(1, 0, 0)

Y

= ABCTYPE(0, 1, 0)

Z

= ABCTYPE(0, 0, 1)

func1

= ABCTYPE(X%A + Y%A + Z%A, &

X

%B + Y%B + Z%B, &

X

%C + Y%C + Z%C) end function func1 end module dllmod

When compiling the second dll (dllmod), I am getting the following error:

Error: prPromoteSym : Illegal KIND & CLASS mix [ABCTYPE]

The error is the same even after adding the SEQUENCE statement to the structure and the /align:sequence to both the compiler an linker command lines. Is there anythingwrong in my code, that's causing such error? Thanks.

[Steven_L_Intel1]

I don't spot a problem on your part. Please report this to Intel Premier Support. I also note that the format of the error is suspicious - that "prPromoteSym" doesn't belong there.

[Steven_L_Intel1]

I see the problem - You should remove the !DEC$ ATTRIBUTES DLLEXPORT::ABCTYPE in the module. One does not DLLEXPORT types - those come with the module - just variables, constants and routines. If you do that, it's fine.

There is still a bug in that a better error message should be given. I'll get that fixed.

[John4]

That seems to be OK at compile time, but since dll1.dll only has types, no export library (Dll1.lib) is created. When linking the second dll (either with or without DEC$OBJCOMMENTand /LIBPATH), I get the following error:

LINK : fatal error LNK1181: cannot open input file '...dll1.lib'

The linker is requesting an import library. Am I missing something?

[Steven_L_Intel1]

What else is in the DLL? If it's only that type definition, you don't need a DLL at all. You need a DLL if you have variables or functions. Type information is in the .mod that is found when you compile the source with the USE - it doesn't come from a DLL.

[John4]

Yes... After posting my previous message, I decided to build from the command line. It seems that the "Fatal Error" output is set by the "Project dependencies" feature in the IDE, not by the linker. Maybe, instead of a "fatal error" it could have been "slight warning".

In my original project, my module includes functions to overloadsome operators for the ABCTYPE type, and therefore the existence of an export/import library is not a concern; the reduced version I uploaded to the Premier Support consists of the type definition only

Thanks for the help anyway.

[Steven_L_Intel1]

You need the DLLEXPORT in the functions.

In the example you posted, you had an OBJCOMMENT directive that referenced the library. If there is no need to reference an export library, then you don't need the DLL at all.

[John4]

Of course I'm using the DLLEXPORT in the functions (I just tried to keep the example I posted as simple as possible).

Now I'm having a different kind of problem. The main dll (Say DLL_A) makes use of code included in two other dll's (DLL_B and DLL_C). DLL_B, in turn, uses code from DLL_C (but everything in DLL_B is declared as PRIVATE, except for the variables and functions having the DLLEXPORT attribute, as well as some TYPEs and INTERFACEs , and therefore DLL_C is not accessible through DLL_B). The build order is:

DLL_C

DLL_B

DLL_A

I don't have any problem for the first two projects, but whenbuilding DLL_A, I get the message:

fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for ...MOD_BC.F90 (code 1)

Where MOD_BC is the module from DLL_A in which I first make use of both DLL_B and DLL_C (through the USE statements and the OBJCOMMENT directive). Since there is no compilation problem when using static libraries instead of dll's, I'm wondering if there is an additional requirement when the dll being invoked also links to another dll. If so, what would it be? Thanks.

[Steven_L_Intel1]

Internal Compiler Error is always a compiler bug. Please send a test case to Intel Premier Support including all source files needed to reproduce it.

You may discover that you have DLLEXPORT directives in additional unnecessary places that are triggering this, but we want to fix the compiler anyway.

[John4]

At least for the code before the CONTAINS statement, I'm sure I only have DLLEXPORT directives for the variables (I removed the ones for the TYPE definitions, as you suggested). And all the public routines after the CONTAINS have the DLLEXPORT attribute.

I'm trying to reproduce the error in a much smaller piece of code, soI can send it to Intel Premier Support.

I have onemore question, regarding the IDE: During debug, I noticed that only the exported variables are accessible from the main code, but they arenot shown in both the Watch and Local windows properly. That is, the values shown arewrong (but when printed, they are right). I also noticed that the value of the variables in both the Watch and Local windows changes depending on the active thread. Is there any way to refer to a variable within the dll (or thread), in away similar to module1::var1, module2::varx, etc? I have tried using the names from the map file, but nothing happens. I'm using VS2005 (though it looks like VS2002 with only half the features). Thanks.

[Steven_L_Intel1]

I know there have been some issues with DLLIMPORTed variables in the debugger, but I don't know the status offhand. I'll have to do some experiments and see where we are. There is no way to references variables per thread that I know of, but I may be missing something.

Yeah, in many ways, VS2005 is a step back from VS2002/2003, at least for Fortran users. But we do continue to work with MS on various issues and things may get better in the future.

[John4]

Sorry if I am bothering too much, but the IVF documentation doesn't help that much when it comes to dll's.

Is there any kind of conflict between the PRIVATE statement/attribute and the DLLEXPORT attribute? I mean, if I define a generic interface, and the specific routines are both privateand have the DLLEXPORT attribute, will the compiler conflict with it? The code would look like:

module dllmod1

interface generic1

module procedure func1, func2

end interface generic1

private

public generic1

contains

integer function func1(A)

!DEC$ ATTRIBUTES DLLEXPORT::func1

...
end function func1
real function func2(A)

!DEC$ ATTRIBUTES DLLEXPORT::func2

...
end function func2
end module dllmod1

Also, what if the interface defines (or overloads) an operator?

[Steven_L_Intel1]

No problem - that's the way to do it. The PRIVATE controls the visibility to the source code of the names, but the compiler has to know a bit more and it can see the DLLEXPORT.

[John4]

The thing is that, while trying to reduce the code, I noticed that by removing the PRIVATE statement from the dll code, and defining the interfaces outside the dll, I am displacing the compiler internal error to the next place (source file) where interfaces from the dllare being used. I tried with both generic interfaces and interface operators, with similar results.

I submitted the issue to Intel Premier today, with a reduced copy of the code. Thanks for the help.