Availability of COMMON variables in DLLs

[ferrad01]

I have DLL1 which contains some variables in a COMMON. DLL1 then calls DLL2 (C++). DLL2 then calls DLL1 (yes I know there is a circular dependency but I get around this by calling the function by address). My question is: are the COMMON variables I mentioned in the first sentence available to routines in the last call or is the 2nd incarnation of DLL1 a completely separate copy with unset common variables?

Adrian

[ferrad01]

I guess I answered my question with a quick test. Indeed the integer variables are the same. Then I guess I'm confused about the allocatable arrays. To get around a problem with the debugger, I have tried this in an INCLUDE file:

real*8, allocatable, target :: x(:)

real*8, pointer : xA(:)

common /test/ xA

In my 1st routine in DLL1 I have:

allocate(x(500))

x(1) = 1234.0

xA => x

Then I call the C++ DLL2, which calls another routine in DLL1. However in this other routine, xA(1) does not have the value 1234.0. It has a value of 0.0. Why? (PS.I can only see this by setting another variable equal to it and looking at that, due to problems with looking at arrays in the debugger.)

Adrian

[Steven_L_Intel1]

In your first case, you did not have a "second incarnation" of DLL1. Just one activation of DLL1 and two calls to it.

In DLL2, did you USE the module created when DLL1 was compiled?

[ferrad01]

No, I am not using Modules, just commons.

[Steven_L_Intel1]

You can share COMMONs between DLLs as long as there isn't a circular reference. So if DLL_A defines a common, the DLL_B and the EXE can link to DLL_A. DLL_A must DLLEXPORT the common and the other two must DLLIMPORT it.

[ferrad01]

Yes, I know this. My original question has been solved, it was to do with the bug in the debugger which I just realized.