IVF DLL using MKL LAPACK routines, issues with DLL dependencies

IVF DLL using MKL LAPACK routines, issues with DLL dependencies


I have a program in Intel Visual Fortran that uses LAPACK functionality from Intel MKL. It works in a normalVS2008 IVF console project with these compiler options:

Additional Include Directories: C:\\Program Files (x86)\\Intel\\Compiler\\11.1\\048\\mkl\\include\\ia32
Additional Dependencies:mkl_lapack95.lib

These are the relevant excerpts from code in Fortran:

use mkl95_precision, only: wp => sp

use mkl95_lapack, only: gesv
call gesv(A,B)

Then I build a Windows Forms application in C# to accept some inputs and present the results. It interfaces with the same Fortran program, but now compiled to a DLL (no change in include directories or additional dependencies), exporting the necessary subroutines like this:

!DEC$ ATTRIBUTES ALIAS: 'getVoltages' :: getVoltages

For now it only fetches a predefined array, and writes it into a textbox control. This works perfectly if I remove these statements from the Fortran code:

use mkl95_precision, only: wp => sp

use mkl95_lapack, only: gesv
call gesv(A,B)

Now, the problems.

If I do include the said statements, the DLL project will still compile, but the Windows Forms application will throw aSystem.DllNotFoundException, pointing to the same Fortran DLL.

Here's the Command Lines for the said Fortran DLL project (using MKL):


/nologo /I"C:\\Program Files (x86)\\Intel\\Compiler\\11.1\\048\\mkl\\include\\ia32" /module:"Release\\\\" /object:"Release\\\\" /libs:dll /threads /Qmkl:parallel /c


/OUT:"Release\\EAPOP-1 FortranDLL.dll" /NOLOGO /MANIFEST /MANIFESTFILE:"C:\\Users\\GIJ\\Documents\\Visual Studio 2008\\Projects\\EAPOP-1\\EAPOP-1 FortranDLL\\Release\\EAPOP-1 FortranDLL.dll.intermediate.manifest" /SUBSYSTEM:WINDOWS /IMPLIB:"C:\\Users\\GIJ\\Documents\\Visual Studio 2008\\Projects\\EAPOP-1\\EAPOP-1 FortranDLL\\Release\\EAPOP-1 FortranDLL.lib" /DLL mkl_lapack95.lib

I also checked both versions of my DLL with the Dependency Walker:

Without use mkl95_precision, only: wp => sp,use mkl95_lapack, only: gesv,call gesv(A,B):

With them (the one I actually need):

Development is done on a x64 Vista machine and the MKL was installed without 64 bit libraries (MKL with them was removedbeforehandin an attempt to narrow down the source ofproblems).

I need advice on how to get all the dependencies right, so that the program would work from any Windows machine with .NET, but without MKL or the IVF compiler. I've only been programing since a few months ago, so I would really appreciate your help.


4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


As I see your program uses MKL Fortran 95 interfaces to LAPACK.
But compiled Fortran codes (binaries) with Fortran95 featuresare compiler dependent.

There are some problems also to call Fortran 95 specific routines from the other languages (see Programming with Mixed Languages section in the IVF documentation).

So its better in such a case touse the original routine sgesv().




The problem was purely a dll dependency issue. Here's what I had to include in the directory of the calling executable for the Fortran dll to work if it used LAPACK driver routines from the Intel MKL:
That's 24 MB to start with. This works only for the old FORTRAN 77 interfaces, however, and there's libifcoremd.dll andlibmmd.dll to make it work with the new Fortran 95 interfaces. On the positive side, this solution works on any windows machines without Intel MKL or the IVF compiler.
What kind of licence would I need to distribute these libraries in my non-commercial applications?
Of course, 24 MB of overhead doesn't look like a rational solution for moderately light engineering apps. Can I use the Intel MKL in a Fortran dll without having to distribute all these libraries? There has to be a more elegant solution. Could I do that with distributions available fromhttp://www.netlib.org/lapack/, and would that lead to a significantly smaller size? I'm not sure the performance gains are worth the size penalty if that is indeed the case.


Hi elengie,1)Please read all licence's related materials intoEnd User License Agreement( see \doc\mklEULA.rtf ). Accordingly to our policy - we cannot comment this topic.2) if 24 Mb is pretty big for your application - then my be you can build the custom dll and it should be much smaller...--Gennady

Leave a Comment

Please sign in to add a comment. Not a member? Join today