Thanks for the notes. I guess the first thing I'm trying to figure out is:
- is my test example usage [with sources, compile commands embeded in the test script posted earlier] incorrect usage of fortran common blocks via dll [if so - whats the correct usage?] '!GCC$ ATTRIBUTES DLLEXPORT' syntax gives compile errors. - is it a bug in cygwin/gfortran? Since stuff other than 'fortran comon block' appears to work [fortran routines, c routines, c-globals etc - without requiring any dllimport/export qualifies in code] - this usage unsupported by cygwin/gfortran? [if so - I should either figure out workarrounds - or not use dlls for this usage] More comments below.. On Wed, 24 Jun 2015, LMH wrote: > If you having trouble communicating with the dll, Its more about 'common block variables' in user code have different adresses than those in the dll [when I expect them to be the same] > 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. We do have c/fortran (user) -> c (.a/.so) -> fortran (.a/.so) wroking fine [on most OSes/compilers]. > 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. Yes - we have this - and it works fine. > 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. Sorry - I don't know what 'same memory namespace' here means.. The test code I posted is just a way to demonstrate the problem and not an exact representative of the 'fortran(user) -> c(library)' interface. thanks, Satish > > 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