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 bette
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
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 t
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_fu
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
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 t
6 matches
Mail list logo
