Re: using fortran common block from dll created by gfortran

[Satish Balay <balay at fastmail dot fm>]

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