Prev: C_LOC and character string
Next: Constructor for a type with pointer component
From: glen herrmannsfeldt on 30 Mar 2010 15:34
Pedro567 <pce(a)ecosimpro.com> wrote:

> We are having a problem to match properly a C struct exported
> as dll using GNU g++ 4.4.0 with a COMMON block in Fortran using
> GNU gfortran 4.4.0. Tt works properly in Linux version, but not
> with Mingw. Probably we are missing something in this platform.
> Any help will be welcomme.

> Code in C++ (compiled as a dll):
> extern "C"
> {
> extern struct {
> int n;
> int k;
> } area_ ;
> }

You shouldn't have padding problems with two variables of
default type. There might still be some C compilers where
(int) is 16 bits, though.

> extern "C" __declspec(dllexport) void view_()
> {
> area_.n= 83;
> printf("c++, n=%d , k=%d \n",area_.n,area_.k);
> return;
> }

> Code in FORTRAN (main program calling the previous dll):
> BLOCK DATA t
> INTEGER N,K
> COMMON /AREA/ N,K
> END

Do verify that the names do match. Some systems, for example,
add an underline on the beginning, too. Also, why is this
in a BLOCK DATA? That should only be needed for initialized
data. Since C always initializes static data, pretty much it
always generates block data, you could have a conflict.
If you need static initialization, do it in C.

> PROGRAM P456
> COMMON /AREA/ N,K
> N = 3
> K = 6
> WRITE(*,*) N,K
> CALL view
> WRITE(*,*) N,K
> END PROGRAM

> We add an extra C file to the dll for compiling independly of FORTRAN:
> __declspec(dllexport) struct {
> int n;
> int k;
> } area_ ;
>
> The problem is that when we compile and execute the program we obtain:
> 3 6
> 83 0
> 3 6
> instead of
> 3 6
> 83 6
> 83 6

> The AREA common block in FORTRAN does not point to the same struct
> area in C++ dll, why?

That is either a link question, or the two names are actually
different. If you can get a link map, that should show the
actual names used. Otherwise, use the -S option to both compilers
and look at the names in the generated assembly code. You don't
have to know anything else about the assembly code, just what it
does with the area name. It could, for example, have more or fewer
underlines, or different capitalization. Also, it could be
conflict with two initialized data structures.

-- glen
From: Pedro567 on 31 Mar 2010 04:53
On 30 mar, 21:34, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> Do verify that the names do match.  Some systems, for example,
> add an underline on the beginning, too.  Also, why is this
> in a BLOCK DATA?  That should only be needed for initialized
> data.  Since C always initializes static data, pretty much it
> always generates block data, you could have a conflict.
> If you need static initialization, do it in C.


Unfortunately removing the BLOCK DATA is not enough. The problem
persists but ONLY when we use the C++ code as a DLL and using
GNU C++ with Mingw (either using Microsoft C++ or GNU C++ in Linux it
works)

> That is either a link question, or the two names are actually
> different.  If you can get a link map, that should show the
> actual names used.  Otherwise, use the -S option to both compilers
> and look at the names in the generated assembly code.  You don't
> have to know anything else about the assembly code, just what it
> does with the area name.  It could, for example, have more or fewer
> underlines, or different capitalization.  Also, it could be
> conflict with two initialized data structures.

Again the names are correct in all cases, they are identical in
Fortran
and in C++ (using the linking tools we detected that). We are
wondering
whether a specif problem of GNU C++ in Mingw platform working with
dlls.
For the moment we have created a workaround passing the address of the
COMMON to C and realigning the struct but it is not very standard
solution.
Perhpas a more experienced user in Mingw platform could provide us
a better hint.
In any case thanks for your help.
Regards
Pedro
 | 
Pages: 1
Prev: C_LOC and character string
Next: Constructor for a type with pointer component