Using IVF and MKL with "libguide"

[brianlamm]

This question is related to using IVF and Intel MKL together, with the necessity of using libguide.lib or libguide40.lib.

The MKL doc reads if one is using the IVF compiler, use the libguide provided with the compiler. Now, my problem is the library "mkl_solver.lib" (I'm assuming IA32 build and target for concreteness), is Not supplied in dll form, so it Must be Statically linked, per the MKL doc. However, the MKL doc goes on to read even if one is statically linking that solver, use the Dynamic lib libguide40.lib. Part of the problem is MKL also supplies libguide40.lib (and libguide40.dll) dynamic libraries, and static library libguide.lib (in case one is Not using IVF to build using MKL). IVF also supplies those exact same Named libraries, even though the IVF libraries are different. Besides, like I wrote above, MKL recommends (strongly) using the dynamic libguide40.lib even if statically linking, and, if one is also using IVF, to use the libguide supplied with IVF, and Not the libguide supplied with MKL.

So my problem is How do I ensure libguide40.lib from the IVF gets used instead of the one shipped with MKL? In the command line I have specified /Qopenmp and /Qopenmp-lib:legacy (thus assuring I get the IVF libguide), But I have also specified (by Necessity since I Must statically link since I'm using mkl_solver.lib) the options /libs:static /threads . In the "additional dependencies" for the Linker (project properties) I have specified all the additional mkl libraries I need to link my app.

Now, in "additional dependencies" I have in one build added "libguide40.lib" and in a different build I have Not included "libguide40.lib" (in front of and in addition to the mkl libraries required). BOTH times the solution built without error, and it appears (based on built dll size alone) the dll built which uses the mkl_solver is Identical. But I did notice in the build log where I specified "libguide40.lib" dependency the IVF lib directory was first searched, and searched in libguide40.lib, and then the mkl (ia32) lib directory was searched in the mkl libraries specified in the additional dependencies, and right after that the IVF lib directory was searched in libguide.lib (no "40").

In the build where I did Not specify libguide40.lib in the additional dependencies only libguide.lib was searched in the IVF lib directory, after the mkl lib directory was searched for the required mkl libraries.

HOW do I determine whether or not libguide40.lib or libguide.lib was used in the build? As I wrote above, regardless of having "libguide40.lib" in the additional dependencies or not, the IVF lib directory was used to search libguide.lib (no "40"). Both the IVF and MKL docs strongly recommend against using libguide.lib (static), so I want to make sure I'm adhering to that recommendation, but cannot find out how to determine Which (libguide40.lib or libguide.lib) was linked against in the build.

-Brian

[TimP]

The same question was posted on Windows Fortran forum; the answer there reinforces the recommendation about relying on an Intel compiler to provide the OpenMP libraries, when linking MKL with Intel compiled objects. For one thing, the 10.1 compilers have an option to specify whether the libguide or libiomp5 (VC9 compatible) are to be used. Another issue is the problem posed by an out of date OpenMP library.
dumpbin /dependents (or equivalent) would show whether you have linked against a dynamic OpenMP library.
I don't know the entire story about why the recommendation against static OpenMP libraries is so vociferous. You would not want to link part of the build against a static library, yet leave undefined references to be satisfied by the dynamic library, particularly with MKL 10 where you have the choice of the "legacy" library (libguide) or the "compatibility" (libiomp5).

[brianlamm]

Thanks Tim,

I was doing fine reading your post until the last sentence.

Now, the MKL docs read one must statically link when using mkl_solver (all platforms). MKL docs, and IVF docs, also read one should not ever link against (static) libguide.lib (aside: why even supply it then?). So, when linking in mkl_solver, I must specify /libs:static in the IVF command line (because I'm using mkl_solver), and also specify /Qopenmp and /Qopenmp-libs:legacy in order to get IVF libguide, and to adhere to MKL/IVF advice of linking against dynamic libguide, I must also specify libguide40.lib in the linker dependencies. If I were not to specify libguide40.lib in linker dependencies, then (I think) the switches /Qopenmp /Qopenmp-libs:legacy and /libs:static would all combine to references being resolved in IVF libguide.lib (static).

And that is where your last sentence in your post worried me a bit. Is it possible, in the case I gave above, the build results in part of it resolving references in static libguide.lib and part of it resolving (other? same?) references at run-time in libguide40.lib export library?

Anyway, thanks for the reply.

-Brian