Problem about share Modules between two DLLs

[gz19]

Hello, Steve and other experts on Fortran:

I have a problemabout sharing dynamic arraysof modules between two Fortran DLLs, I have spent some time on searching this forum,does not solvemy problme.

The problem is

A commercial software have a userinterface written in C or C++, theuser interfacecalls a DLLwhich was written in Fortran years ago, which is the main part of the software, We canconfigure in the user interface instructing the Fortran DLL to call another user-programmedDLL(call RTE, RunTime Extension) , by thisuser-programmed DLL, we can enhance the software capability.

The RTE developer's guide give out a data dictionary includingmany exported COMMONs, and the Module definition.All the variables withinthe Modulesare also exported,many of these variables are dynamic allocated arrays. The RTE developer can manupilate those COMMONs and module variables.

I have no problem about the COMMONs,as for the Modules, the scalarswithin the Modules such as Interger, Real are ok, it seems Dynamic allocated arrays cannot run as expected. we cannot access the dynamic arrays.

I found this thread is very useful but did not solve my problem.
http://softwareforums.intel.com/en-us/forums//topic/41940

I found when we allocate some dynamic arrays in the DLL1, then try to change the arrays valuse in DLL2, it cannotaccess the array. Weird enough, if I allocate some dynamic arrays in a .exe, then try to access the value in a DLL, it is fine.

Ihave attachedthe two testing projects,extract themat C: to preserve the project settings, you can see my problem

Another comment is if I use C or C++ Module_Name_mp_Array_Name to access these arrays, it works fine, the problem is we have thousands of fortran linescodes available, those code using the same data structure with the software DLL. If we can link those codes, it will save us many time to covert those code to C.

[Steven_L_Intel1]

You have a circular dependency in your DLLs. DLL1 calls routines in DLL2 which in turn depends on a variable exported by DLL1. While it is possible to mangle the build to accomodate this, it is not straightforward. The correct solution is to create a new DLL, DLL3, that contains just the module. Then DLL1 and DLL2 can link against DLL3 (and DLL1 can link against DLL2.) This will ensure that both DLL1 and DLL2 can see the exported allocatable variable.

[gz191]

Hi, Steve. I works just as you said as I attached the modifiedfile.

But that's not what I needed. My problem is I cannot get the source code of DLL1 and to link them as I want, The structure of my problem is just like the first attached project. I have to develop the DLL2 without the source code of DLL1 and MAIN. Ionly have the Module files used in DLL1.

When I use C++ pointer to access those module dynamic arrays it works just fine. Whythe Fortran code cannotaccessit? Isthere any special tricks to linka FortranDLL with anotherexisting DLL with Module dynamic arrays.( do not have source code for this existing DLL).

Thanks anyway!

[Steven_L_Intel1]

I don't know what you are doing in C++. There are no "special tricks" to using a module in a DLL. I also don't understand how you can have a circular reference and NOT have the sources to both DLLs. Perhaps your example is not actually representative of the problem?

[gz191]

I mean I do not have the source code of main program and DLL1 part code, they are commercial software distributed as .exe and .dll, I need toprogram the DLL2 source code andcompile it to the DLL2 dll.

When I use C++ programing the DLL2, Ijust setup adll project and the compiled it to a dll whichcanrunwith DLL1 andmanupilate the DLL1's exported COMMONs and Modules, But we have manyavailable Fortran Code , and I try to compile it to adllwhich isDLL2 part of the example. the compiled dll from fortran code cannot access the DLL1 module's dynamic arrays.

In the example source code, I am justtrying tosimulate the real situation I met now.

Thanks for you reply anyway!

--------------------------------

G. Zhang

[Steven_L_Intel1]

If it is as you describe, how does the precompiled DLL1 get access to variables or routines in your DLL2? There isn't any mechanism I can think of that would allow that. I still seem to be missing something about the actual arrangement.

[gz191]

That's exactly the problem I face now, DLL1 do not access any variables in DLL2, InDLL2 only 3 subroutinesexport to be accessedby DLL1, Initialize, Main, Exit. DLL2 access the exported COMMONS and Modules in DLL1 and changethe valuethen write back to memory. we need to configure on the MAIN win32 interface program instructing DLL1 to call these 3 functionsin DLL2, I think when we do theconfiguration, we pass3 pointersto functions to the DLL1,then DLL1 can call DLL2 at three different points.The DLL1.lib file isavailable with thesoftware distribution

Weare developing on thecommercial software's programer interface,that's the structure of theinterface. I know it is not good, but there are historical and marketreasons why it is. thanks

[Steven_L_Intel1]

Ok - so DLL1 doesn't link to DLL2 at all. It relys on routine pointers passed from the main. That's fime. Now what about the COMMONs? How does that fit in? DLL2 cannot access any global variables that weren't defined when it was linked.