If you having trouble communicating with the dll, it might make more sense to create a generic c dll and embed the fortran in the c dll as a subroutine. It is generally not a problem to call a fortran subroutine from c code though there are some syntax specifics to follow. Your communication with the dll could follow standard c protocols. Since c code and fortran code will have their own namespaces, your fortran includes, common block, etc, shouldn't be a problem since those variables will only be linked to the fortran objects. Your fortran src files will be run through the fortran pre-processor so your common block should be fine. Your c src files will be run through the c pre-processor. The c objects won't know anything about the fortran global variables but you can exchange what you need to between the c and fortran in the call to the fortran subroutine. You end up with two copies of allot of things but this is a decent way to get fotrran code to talk to the modern programming world.
The only way I know to use the same memory namespace for both c and fortran files is to run the fortran through the c pre-processor (name your fortran src files .FPP). This lets you use c style includes and compiler directives in your fortran code but does not support a common block. You would have to declare global variables in c style includes. LMH Satish Balay wrote: > Thanks for the note. > > I had previously tried something similar - using the directives from > http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html > > However - I get errros. > >>>>>>>>>>> > balay@ps4 ~/junk > $ cat cb_func.f > subroutine cb_func() > !GCC$ ATTRIBUTES DLLEXPORT :: cb_func, /cb/ > common /cb/ cvar > integer cvar > cvar = 2 > end > > balay@ps4 ~/junk > $ gfortran -c cb_func.f > cb_func.f:2.40: > > *GCC$ ATTRIBUTES DLLEXPORT :: cb_func, /cb/ > 1 > Error: Invalid character in name at (1) > > balay@ps4 ~/junk > $ > <<<<<<<<<<<<< > > Wrt 'common blocks' vs 'module' - this usage is part of a c library > supporting fortran interfaces [and works generally on various OSes, > compilers]. We haven't worked with dlls on windows much. However this > issue came up on such an attempt with cgwin/gnu compilers. > > PS: I'm not subscribed to the ML - it would be great if I'm included in cc: > > Thanks, > Satish > >>>>>>>> > Hi, > > while this is not directly related to gfortran on Cygwin, this article > might help you appreciate the issues involved: > https://software.intel.com/en-us/node/535307 > > Are you bound to common blocks? If not, you may get better results > when you put the data in a module. > > Regards, > > Arjen > > On Tue, 23 Jun 2015, Satish Balay wrote: > >> Hi Cygwin, >> >> I'm debuging an issue with dlls with cygwin gnu compilers - and have >> narrowed down the issue to the attached test case [script]. >> >> Could you guide me to correct usage of 'fortran common block' with dlls? >> >> [In this example - using fortran 'common block' via static library >> works. However the same code using a .dll fails] >> >> Thanks, >> Satish >> >> --------- >> >> balay@ps4 ~/junk >> $ ./cb_test.sh >> + cat >> + cat >> + rm -f '*.o' '*.dll' '*.a' '*.exe' >> + gfortran -c cb_func.f cb_main.f >> + ar cr libcb_static.a cb_func.o >> + gfortran cb_main.o -L. -lcb_static -o cb_main_static >> + gfortran -shared -o libcb_dynamic.dll cb_func.o >> + gfortran cb_main.o -L. -lcb_dynamic -o cb_main_dynamic >> + ./cb_main_static >> GOOD COMMON BLOCK >> + ./cb_main_dynamic >> BAD COMMON BLOCK >> >> >> balay@ps4 ~/junk >> $ uname -a >> CYGWIN_NT-6.1 ps4 2.0.4(0.287/5/3) 2015-06-09 12:22 x86_64 Cygwin >> >> balay@ps4 ~/junk >> $ gfortran --version >> GNU Fortran (GCC) 4.9.2 > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
