Strange error with a simple DLL

[Arjen_Markus]

Hi,

I have run into a strange error while experimenting with a DLL. The program works fine
when compiled gfortran (the experiment fails, but that is another matter), but it crashes
when compiled with Intel Fortran 11.1. At start-up it produces a messagebox with an
error message R6034 - the C runtime library was apparently wrongly loaded.

Here is the code for the main program:

program exchange1

use datadll

implicit none

integer :: value

character(len=1) :: dummy

value = 123

write(*,*) 'Exchange 1: Setting item to ', value

write(*,*) 'Press ENTER'

read(*,'(a)') dummy

call putitem( value )

write(*,*) 'Exchange 1: Set item to ', value

write(*,*) 'Press ENTER when ready'

read(*,'(a)') dummy

end program exchange1


And this is the code for the DLL:

! datadll.f90 --

! Define a module with data - the module is part of a DLL

!

module datadll

implicit none

real, dimension(10) :: array

!dec$ attributes dllexport:: array

integer :: item

!xxdec$ attributes dllexport:: item

contains

subroutine initdata

!dec$ attributes dllexport:: initdata

call random_number( array )

end subroutine initdata

subroutine putitem( value )

!dec$ attributes dllexport:: putitem

integer :: value

item = value

end subroutine putitem

subroutine getitem( value )

!dec$ attributes dllexport:: getitem

integer :: value

value = item

end subroutine getitem

end module datadll


Here is the batchfile I use to compile it:

ifort -dll datadll.f90

ifort exchange1.f90 datadll.lib


The funny thing is, if I call the subroutine initdata (this is in another test program) it works
fine. I do not see what the difference is between the two and why the _presence_ of a call to
putitem should crash the program at start-up (it happens before any statement is executed!)

Can anyone solve this puzzle?

Regards,

Arjen

[mecej4]

Check your IVF installation. With IVF11.1.065, I get no errors/crashes

[bash]S:LANG>Exchange1
 Exchange 1: Setting item to          123
 Press ENTER

 Exchange 1: Set item to          123
 Press ENTER when ready[/bash]

[Steven_L_Intel1]

Have you placed copies of any Microsoft Visual C++ DLLs in the problem program's folder?

[Arjen_Markus]

mecej4, Steve,

the directory contains no DLLs from MicroSoft Visual C++.

The odd thing is that the following program that uses _the same_ DLL in the same directory
has no problem at all:

! getdatadll.f90 --

! Get data from a DLL

!

program getdatadll

use datadll

implicit none

call initdata

write(*,*) array

end program getdatadll

Note: I run the compiler in a DOS-box via the Start menu option "Fortran Build Environment for applications on IA-32"

The compiler works fine for several large programs I build on the same machine.

Regards,

Arjen

[Arjen_Markus]

Actually, it gets worse:

! getdatadll.f90 --

! Get data from a DLL

!

program getdatadll

use datadll

implicit none

integer :: value

call initdata

write(*,*) array

value = 11

call putitem( value )

value = 12

call getitem( value )

write(*,*) value

end program getdatadll

(so with calls to the routines that cause the trouble in the other program) runs fine.

Even if I leave out the call to initdata and the first write statement it works fine.

The exchange1 program I posted still gives this nasty trouble.

Regards,

Arjen

[Steven_L_Intel1]

Download Dependency Walker, run it and drag your EXE onto the window. From the File menu, select Save As to save a .dwi file. Attach the .dwi file to a reply here.

[Arjen_Markus]

Yesterday, I had a chance to test the set-up on a completely independent installation (I was presenting
the course I wrote the original program for). It turned out that:
- Compiling the DLL and the programs in a DOS-box set up for Intel Fortran I got the same problems
- Compiling the DLL via MS Developer Studio and then _copying_ the previous executables into the
Debug directory made the programs work without a fuss.

I sent the DWI-file to Steve directly, but Dependency Walker only complained about a DWMAPI.DLL it could
not find. There was no discernible difference between the reports for the program that does work and the
program that does not. Well, I remain puzzled ;)

Regards,

Arjen