Common block problem

Common block problem

Hello,

In the attached project two arrays contained in common blocks are initialized. If the third party static library used in this project is linked into the application, initialization of the second array will partly overwrite the other array. If the thrid party array is not linked in, this doesn't happen.

Also if one or both arrays are not contained in common blocks, the problem is not there.

The actual project, where I am faced with this issue, is too complex to simply place the arrays outside common blocks (legacy code with lots of equivalenced arrays and mixing of character strings, reals and integers)

I understand that this is mainly an issue of the third part library supplier, but they are not so familiar with fortran programming (the library is a C-library). The fortran interfaces to the library are correct (functions correctly in other applications).

I was hoping that someone has some idea about what the cause of the issue might be, which would make it easier to give some directions to the supplier.

Note that for testing a demo hasp key (the thrid party library is used for hasp key login) is not required

Walter Kramer

AllegatoDimensione
Download hasp.zip830.11 KB
5 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

The common blocks should match C structs in the traditional way

extern struct {

    float r2[760];

  } U2;

...

It looks like you have mis-matching definitions and array over-runs somewhere.

f2003 iso_c_binding gives you somewhat more portability.  For starters, on Intel compilers, c_float has the value 4 for Ifort which you have used.  The Modern Fortran Explained textbootk by Metcalf, Reid and Cohen gives fuller advice.

You have not described what the library expects you to declare, but it does have the common blocks as symbols. With the code that you gave, R2(513:) are clobbered by setting M2, so the library is doing something that is perhaps not proper. By padding up the /U4/ block with a sacrificial array, I found that the clobbering can be suppressed; however, you need to get the problem understood better and fixed properly.

  REAL(4) :: M2,MM
  COMMON /U4/  MM(300),M2(6000)

Terminology quibble - you aren't initializing the arrays - you are assigning to them.

The library exports a symbol with the same linker name as the linker name used for the Fortran common blocks.  If those symbols are unrelated (i.e. the library is not trying to refer to the common blocks in some way, which is what I understand from your description) then you have an unfortunate name clash - try changing the name of the Fortran common blocks to be something different. 

>dumpbin /symbols DebugMain.obj
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.
Dump of file DebugMain.obj
File Type: COFF OBJECT
COFF SYMBOL TABLE
000 00000001 ABS    notype       Static       | @feat.00
001 00000000 SECT1  notype       Static       | .text
    Section length  168, #relocs   13, #linenums    0, checksum        0
003 00000000 SECT1  notype ()    External     | _MAIN__
004 00000000 SECT2  notype       Static       | .debug$S
    Section length  344, #relocs   10, #linenums    0, checksum        0
006 00000000 SECT7  notype       Static       | .debug$T
    Section length   44, #relocs    0, #linenums    0, checksum        0
008 00000000 UNDEF  notype       External     | _HASPMODULE_mp_VENDOR_CODE
009 00005DC0 UNDEF  notype       External     | _U4
00A 00000BE0 UNDEF  notype       External     | _U2
00B 00000000 SECT3  notype       Static       | .rdata
...
>dumpbin /symbols sourcelibhasp_windows_demo.lib | FIND "_U2"
00C 00002600 SECT2  notype       External     | _U2

(If the library is trying to refer to the common blocks, then you effectively have inconsistent declarations of the common block content.)

Thank you all for your suggestions.

Ian,

You are right. The symbols are unrelated, so there is indeed an unfortunate name clash. In fact, in the original project, there is a complete range of name clashes. I changed the names of the Fortran common blocks as you suggested and now everything functions as it should.

Thanks a lot,

Walter Kramer

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi