Re: using fortran common block from dll created by gfortran
Hi Satish, I would have expected the /cb/ notation to work, but if you export the individual variables instead, it does get compiled. However, my test program shows that the data in the main program are not the ones in the DLL, even though I applied both DLLEXPORT and DLLIMPORT. It might be better to use "accessor" functions/routines to get the data from the common blocks in the C layer you are using. Regards, Arjen -- 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
Re: using fortran common block from dll created by gfortran
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 > >> +
Re: using fortran common block from dll created by gfortran
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
Re: using fortran common block from dll created by gfortran
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
Re: using fortran common block from dll created by gfortran
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 2015-06-24 6:30 GMT+02:00 Satish Balay : > 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
