Solved: Compaq Visual Fortran 6.6: Dynamic-Link Library (DLL) and Module - Page 3

Bakhbergen · ‎01-09-2019

I need to create and use dynamic-link library (DLL) for Fortran application using Compaq Visual Fortran 6.6. The following code works just fine:

PROGRAM AMAIN1

IMPLICIT NONE

REAL(8):: A,B,S

A = 1D0

B = 2D0

CALL SUBRO1(A,B,S)

PRINT*, 'S = ', S

END PROGRAM AMAIN1

SUBROUTINE SUBRO1(A,B,S)

!DEC$ ATTRIBUTES DLLEXPORT :: SUBRO1

IMPLICIT NONE

REAL(8):: A,B,S

S = A + B

RETURN

END SUBROUTINE SUBRO1

The result is correct:

S = 3.00000000000000

Press any key to continue

However, if I implement the same algorithm using the module, I get inconsistent result (i.e. zero):

PROGRAM AMAIN2

USE MODUL2

A = 1D0

B = 2D0

CALL SUBRO2

PRINT*, 'S = ', S

END PROGRAM AMAIN2

MODULE MODUL2

IMPLICIT NONE

REAL(8):: A,B,S

END MODULE MODUL2

SUBROUTINE SUBRO2

!DEC$ ATTRIBUTES DLLEXPORT :: SUBRO2

USE MODUL2

S = A + B

RETURN

END SUBROUTINE SUBRO2

The result is incorrect:

S = 0.000000000000000E+000

Press any key to continue

As can be seen above, DLL contains only subprogram in both cases (SUBRO1 and SUBRO2, respectively). I have built DLL and LIB files from the visual development environment. The second case (with the use of module) represents the structure of my large source-code so I need to resolve this issue. Any advice would be greatly appreciated.

BTW, the same algorithm without using the DLL works well and gives correct result:

PROGRAM AMAIN3

USE MODUL3

A = 1D0

B = 2D0

CALL SUBRO3

PRINT*, 'S = ', S

END PROGRAM AMAIN3

MODULE MODUL3

IMPLICIT NONE

REAL(8):: A,B,S

END MODULE MODUL3

SUBROUTINE SUBRO3

USE MODUL3

S = A + B

RETURN

END SUBROUTINE SUBRO3

The result is correct:

S = 3.00000000000000

Press any key to continue

Steve_Lionel · ‎01-16-2019

I was able to log in to Bakhbergen's PC and eventually figured out the problem.

In CVF 6.6C (and the later Intel compilers), when you USE a module that has a DLLEXPORT directive, that turns into a DLLIMPORT. But it wasn't always this way, and the version he has doesn't have that behavior. Before that change (which my memory says I lobbied for), you had to supply a separately compiled .mod where the source had DLLIMPORT instead of DLLEXPORT. When I did this, the program worked. I don't remember exactly which update had this change.

So what he needs to do is have two versions of MODUL2.f90, one with DLLEXPORT and one with DLLIMPORT. The DLLEXPORT version gets built into the DLL. The DLLIMPORT version would just be compiled (/c) and only the .mod used, not the ,obj, when linking the main program. Messy, I know, which is why we changed it.

We also discussed why he is using that specific old version, and I understand the reasons (which I will not go into further here.)

View solution in original post

Bakhbergen · ‎01-16-2019

Finally, solution was found. Steve, thank you very much. Your kind help is highly appreciated. I should have asked for help in fixing this issue via remote desktop connection earlier.

I would also like to thank you so much, mecej4, gib, for providing very useful information.

As I mentioned, I have been using Compaq Visual Fortran 6.6 as well as PGI Visual Fortran within the Microsoft Visual Studio 10. Now I am considering gradually switching to GFortran. It looks like the command line environments have some advantages over visual development environment. I will try to learn about using the command line interface.