X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id
	:references:mime-version:content-type; q=dns; s=default; b=l61sV
	ieC+6GfFI/qanzxq2Dna4IZCyW8flKWB1YjaFg6Yp6gXi0Td7VGo+qf7MonMqsmP
	bAae7e3n+IS8kJVTbxDjZLKsYoSPG4RsQSBw0PunI8q8MqqijXhsMB4a094gi6qY
	Sk3ceypRx09cIRbRD/pVVjSMUa7oHmZCSw9jzk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id
	:references:mime-version:content-type; s=default; bh=Wu2St2KrlNn
	cgaFL6U/RH+T5GB4=; b=nY3IpixZ7SyBZdo66MMn6lMr27+UOB4YCHTKDOTKEp7
	pkCh41Wp74ZYCa68UF/f+eMY4uS8WOYYhcjndoD249wofCdKjCTUoVxxqTuLz2P/
	5ox7t21vu0iz6GXO8oYW/lFtucbuiXe2qesCIrnCOBpqIPqlaGa14Efgebe8m610
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: out5-smtp.messagingengine.com
Date: Wed, 24 Jun 2015 20:46:09 -0500 (CDT)
From: Satish Balay <balay AT fastmail DOT fm>
To: LMH <lmh_users-groups AT molconn DOT com>
cc: cygwin AT cygwin DOT com
Subject: Re: using fortran common block from dll created by gfortran
In-Reply-To: <558B4739.9050303@molconn.com>
Message-ID: <alpine.LFD.2.11.1506242011160.26805@asterix>
References: <alpine DOT LFD DOT 2 DOT 11 DOT 1506232245380 DOT 28689 AT asterix> <alpine DOT LFD DOT 2 DOT 11 DOT 1506241021130 DOT 22435 AT asterix> <558B4739 DOT 9050303 AT molconn DOT com>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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 AT ps4 ~/junk
> > $ cat cb_func.f
> >       subroutine cb_func()
> > !GCC$ ATTRIBUTES DLLEXPORT :: cb_func, /cb/
> >       common /cb/ cvar
> >       integer cvar
> >       cvar = 2
> >       end
> > 
> > balay AT 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 AT 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 AT 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 AT 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 AT 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