I am trying to call a Fortran DLL from a C# program. I have successfully accomplished that with a simple program. and I have seen data passed back and forth between the program and my test DLL. However, when I add complex (and uncalled) subroutines to my test DLL, I get an 'Additional information: An attempt was made to load a program with an incorrect format.' exception. The complex subroutines have worked as part of a compiled Fortran program and they compile just fine in the DLL. Is there some switch I am missing? I am using VS2005 and the Intel Fortran Compiler 9.1.3192.2005. Help!!!
連結已複製
17 回應
Quoting - mountain_ike
'Additional information: An attempt was made to load a program with an incorrect format.' exception.
Hi,
is this the 'System.BadImageFormatException'? Do you build and run dll on the same platform? I mean 32/64-bit? (usually you can get this kind of exception if you build dll on 32-bit and move the code to 64-bit, C# rebuilds while dll doesn't). More info is required, I'm afraid.
A.
Quoting - ArturGuzik
Hi,
is this the 'System.BadImageFormatException'? Do you build and run dll on the same platform? I mean 32/64-bit? (usually you can get this kind of exception if you build dll on 32-bit and move the code to 64-bit, C# rebuilds while dll doesn't). More info is required, I'm afraid.
A.
OK then. I understand that you went through standard steps: (1) checking exports using dumpbin (2) checking dependencies using Dependency Walker (3) trying link without Library Dependencies (4) verifying that you have not specified something (strange) in Additional Dependencies (linker Input).
Does the dll work if called from Fortran exe?
A.
Does the dll work if called from Fortran exe?
A.
Quoting - ArturGuzik
OK then. I understand that you went through standard steps: (1) checking exports using dumpbin (2) checking dependencies using Dependency Walker (3) trying link without Library Dependencies (4) verifying that you have not specified something (strange) in Additional Dependencies (linker Input).
Does the dll work if called from Fortran exe?
A.
Does the dll work if called from Fortran exe?
A.
Quoting - mountain_ike
I did not check if the DLL would run in Fortran, and it does NOT! However, I am simply extracting elements from a working program to put into a DLL. The subroutines are literally copied out of a working directory into a new project and compiled into the DLL. Why would the program work but an exported DLL fail? Sorry if these are dumb questions, but while I am an experienced Fortran programer, I know nothing about dealign with DLLs...
subroutine AMPdUP(testin,testout)
!DEC$ ATTRIBUTES DLLEXPORT::AMPdUP
!DEC$ ATTRIBUTES ALIAS:'AMPdUP'::AMPdUP
implicit none
real testin,testout
testout=2.0
end subroutine
If this is the only file in the DLL project, everything works. If I add the files containing a bunch of other subroutines (from the working program) to the project - without any additional exports or changes to this subroutine - the DLL crashes. I'm baffled!
Quoting - mountain_ike
Why would the program work but an exported DLL fail?
frustrating, isn't it? Well, on the positive note, I'd say your dll problem is not related to calling it from C#, so we're substantially narrowing down the possibilities. With calls to dll many things can go wrong. Trying to track the problem, (using pure Fortran):
(1) check the dependencies (Dependency Walker) and export symbols (dumpbin) for "working" dll call
(2) check the same after adding new routines (any changes (dependencies))?
(3) make sure you're statically linking (your dll project), this will help avoiding a few problems
How do you "dll import" your routine(s) in main (use explicit interfaces)? Add *.lib as a reference to your project, maybe compiler/linker will detect something.
Are the other routines depending on something else (MKL?, other libraries?) I assume that you're adding the routines as a source code.
A.
EDIT
what's the crash info displayed (message) once called from Fortran exe?
Quoting - ArturGuzik
frustrating, isn't it? Well, on the positive note, I'd say your dll problem is not related to calling it from C#, so we're substantially narrowing down the possibilities. With calls to dll many things can go wrong. Trying to track the problem, (using pure Fortran):
(1) check the dependencies (Dependency Walker) and export symbols (dumpbin) for "working" dll call
(2) check the same after adding new routines (any changes (dependencies))?
(3) make sure you're statically linking (your dll project), this will help avoiding a few problems
How do you "dll import" your routine(s) in main (use explicit interfaces)? Add *.lib as a reference to your project, maybe compiler/linker will detect something.
Are the other routines depending on something else (MKL?, other libraries?) I assume that you're adding the routines as a source code.
A.
EDIT
what's the crash info displayed (message) once called from Fortran exe?
As it turns out, when I build the simple DLL it has MSVCR80D.dll and KERNAL32.dll for dependencies. When I build the full complex DLL is has 2 more dependencies: libifcoremdd.dll and libmmdd.dll. The crash states that the libifcoremdd.dll is "either not designed to run on Windows or it contains an error." It suggests that there is an error with the libifcoremdd.dll and that I should contact the vendor...
I found an answer on a Cornell University web site...apparently I need to add the offending Fortran DLLs directly to the directory with the executable. From what I've read, it appears to be a problem with the debugging version of the DLLs. I wonder if it exist for later versions of the compiler?
Are you copying debug DLLs to another system that does not have IVF and VS installed? Don't do that - such DLLs are not redistributable. Build your DLLs as Release confgurations instead. Your license does not allow copying of the debug run-time DLLs.
Quoting - mountain_ike
I found an answer on a Cornell University web site...apparently I need to add the offending Fortran DLLs directly to the directory with the executable.
So we started with 'System.BadImageFormatException' in C# and ended up that actually you're using the dll on different machine and try to redistribute debug dll(s)? is this the case?
A.
Quoting - Steve Lionel (Intel)
Are you copying debug DLLs to another system that does not have IVF and VS installed? Don't do that - such DLLs are not redistributable. Build your DLLs as Release confgurations instead. Your license does not allow copying of the debug run-time DLLs.
Ok. When the compiler installs, it asks you if it is ok to update the PATH system environment variable so that DLL-linked applications can run. It would appear that you did not allow this to happen.
Edit your system PATH environment variable to add:
%IFORT_COMPILER11%libia32
Edit your system PATH environment variable to add:
%IFORT_COMPILER11%libia32
Quoting - Steve Lionel (Intel)
Ok. When the compiler installs, it asks you if it is ok to update the PATH system environment variable so that DLL-linked applications can run. It would appear that you did not allow this to happen.
Edit your system PATH environment variable to add:
%IFORT_COMPILER11%libia32
Edit your system PATH environment variable to add:
%IFORT_COMPILER11%libia32
Quoting - mountain_ike
However I might be going back to the 64 but problem. When it crashes it crashes on the file libifcoremd.dll in the EM64T sub-directory. Why would it go there rather than to the ia32 directory?
Hi,
now we're close to (finally) make it. Are you using version 11.x? This Compiler 9.1.3192.2005 is the VS integration number, isn't it? If not you need to adjust path entry Steve gave you last time. It looks as if you've installed 32 and 64 development components. In VS are you using correct (32-bit) project configuration?
A.
Quoting - ArturGuzik
Hi,
now we're close to (finally) make it. Are you using version 11.x? This Compiler 9.1.3192.2005 is the VS integration number, isn't it? If not you need to adjust path entry Steve gave you last time. It looks as if you've installed 32 and 64 development components. In VS are you using correct (32-bit) project configuration?
A.
Yes, this is a problem. When on a x64 system, the compiler install does not know if you are running 32-bit or 64-bit executables. I believe that for version 11, it puts only the "native" lib folder in PATH. Unfortunately, this means that you have to do something special to run 32-bit apps linked to the DLL libraries. It isn't a compiler issue in that the compiler is not in the picture when the choice is made.
We had looked at using shared assemblies, the way Microsoft does, but MS warned us away from that as leading to further problems. They did not offer a better alternative though.
We had looked at using shared assemblies, the way Microsoft does, but MS warned us away from that as leading to further problems. They did not offer a better alternative though.
Quoting - Steve Lionel (Intel)
Yes, this is a problem. When on a x64 system, the compiler install does not know if you are running 32-bit or 64-bit executables. I believe that for version 11, it puts only the "native" lib folder in PATH. Unfortunately, this means that you have to do something special to run 32-bit apps linked to the DLL libraries. It isn't a compiler issue in that the compiler is not in the picture when the choice is made.
We had looked at using shared assemblies, the way Microsoft does, but MS warned us away from that as leading to further problems. They did not offer a better alternative though.
We had looked at using shared assemblies, the way Microsoft does, but MS warned us away from that as leading to further problems. They did not offer a better alternative though.
