Help on linking with MKL 10.0.011

Help on linking with MKL 10.0.011

I'm studying how to program with mkl and I wrote a test program that call vmlSetMode and vdAsin function. Now the problem is that I can compile it via mkl 9.1, but failed to compile it with mkl 10.0.011. I included the header file "mkl_vml.h", and specified these corresponding environment path variables to link with the library.

The following is the compilation process:

icc -o test test.cpp -lvml ( link with mkl 9.1 ok)
icc -o test test.cpp -lmkl_vml_ia ( failed to link with mkl 10.0.011:
undefined reference to `vmlSetMode'
undefined reference to `vdAsin')

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

I don't know the answer to your specific problem. In general, the new "layered" scheme of MKL 10 requires linking multiple libraries. For example, it may be necessary to append -lmkl_core.
Several of us had to search to find the new library link sequence. For example, you can use 'nm libmkl_core.a | grep vmlSetMode' to see quickly whether that symbol is defined in that library.

As tim18 said, in MKL 10.0 new layered model was implemented. Now we have three layers: interface (libmkl_intel.a/.so), threading (libmkl_intel_thread.a/.so, libmkl_gnu_thread.a/.so, libmkl_sequential.a/.so) and computation (libmkl_core.a/.so). In brackets I put libraries enough for successful link with VML at linux IA32 (for more information you can look into documentation). When you linking your application, you should use one library from each layer. For example, if you want receive sequential version of VML you should link your application with following libraries: libmkl_intel.a/.so + libmkl_sequential.a/.so + libmkl_core.a/.so. In case of dynamical MKL usage, path to libmkl_vml_XXX.so libraries should be provided to OS dynamic loader (commonly, LD_LIBRARY_PATH system environment variable used for this purpose).

Let us know if you have any questions.

Andrey

I'm using IVF 10 and MKL 10 inVS2005 on a C2D Vista.

The digegasx/90 example compiles, links, and loads in Win32 with the
linker pulling in mkl_c.lib, libguide.lib, and mkl_ia32.lib, the same
as with MKL 9.1.
However, in EM64T, whereas linking to libguide.lib and mkl_em64t.lib
with MKL 9.1 the sample compiles and links, with MKL 10 is takes all of
mkl_solver_lp64.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib
libguide40.lib with MKL 10.
How does one select the requisite libs in Win32 and EM64T? I've RTFM
and its still as clear as mud.
Gerry

Gerry,

which functionality from MKL are you planing to use?

Andrey

Currently the interval linear solverssincemkl 9.1.027 which, at least for em64t, got broken in moving to 10.0.012. I have it working again with the current mkl build but this was by trial and error rather than by rational decision as the documentation isn't clear on what one has to make available to the rather dim linker. The blas and linpackinterfaces built fine via nmake. More useful to Windows users than the new multilayer redesign of mkl would be its integration into VS 2005, with wizards, add-ins, and online help.

Thanks

Gerry

ps

Excuse the rant but I happen to think that mkl is a useful product that can be made even better.

Gerry

The best way to find proper sequence for linking is to go in exampleinterval in MKL release. Then it is necessary to set envriroment variables like this

C:ProjectsMKL10ia32lib>set lib=C:ProjectsMKL10ia32lib;%lib%

C:ProjectsMKL10ia32lib>set path=C:ProjectsMKL10ia32in;%path%

C:ProjectsMKL10ia32lib>set include=C:ProjectsMKL10ia32include;%include%

In the directory exampleinterval you need to type 'nmake help' and you will see the following

C:ProjectsMKL10examplesinterval>nmake help

Microsoft Program Maintenance Utility Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.

Usage: nmake {lib32/dll32/libem64t/dllem64t/lib64/dll64} [function=name+]
[THREADING=threading_name]
name - function name, look at the file ias.lst for details
Intel Fortran Compiler as default
threading_name - can be parallel or sequential. Default value is parallel.

Let's type 'nmake lib32' and we see a long outputof running. If we look at it carefully, we find a sequence of MKL libs needed for linking like this

ifort /MT /Fo_resultsintel_parallel_32_lib /Fe_resultsintel_parallel

_32_lib sourcesitrtrsx.f90 mkl_solver.lib mkl_intel_c.lib mkl_intel_thread.lib

mkl_core.lib libguide40.lib

It is also possible to run just one example. The list of examples is located in file ias.lst

It should be noted that new layered model is not supported for interval solvers in MKL 10 Gold. This means the interval solvers can only work with Intel threading (e.g. any application calling them should be linked with libguide) or without any threading.

All the best

Sergey

Sergey,

Thanks for the response.

The Additional Dependencies required by the linker are

mkl_c.lib libguide.lib mkl_solver.lib mkl_intel_thread.lib

for win32 and

mkl_solver_lp64.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib libguide40.lib

for em64t, respectively.

Why are they different? Why does win32 require c while em64t doesn't? Why does em64t require core but win32 doesn't? What's the difference between libguide and libguide40?

Thanks

Gerry

mkl_c.lib simply means a library conforming to ifort conventions, the alternative (to support CVF) being mkl_s. As there is no question of supporting CVF with 64-bit libraries, and no 64-bit support for the ABI in mkl_s, you don't have the same choice there.

I'm patently not using CVF but rather IVF. My questions still stand, unanswered.

Gerry

Sorry, Gerry, from now on I'll take the hint that even those questions of yours which appear to have a straightforward answer aren't meant to be answered.

Tim, I too read the User's Guide and prior to posting I knew that mkl_c.librelated to IVF's calling convention which differsfrom CVF's.

What I wondered about was why mkl_c.lib is required for the win32 platform but not for em64t when both x86 and x64 use the Intel calling convention. If you have an obvious answer to this then please share it. Ditto for the other queries, which however naive they may turn outto be,have no in-your-face answers that are obvious to you or to me.

Thanks anyways,

Gerry

Gerry,

"c" and "s" letters in libraries names means "cdecl" and "stdcall". Stdcall calling convention is absent at EM64T and IPF.

Andrey

Gerry,

Here is a smalladdition to Andrey's replyregarding libguide libraries:

libguide40.lib is the interface library for dynamyc threading library and libguide.lib is thestatic threading library.

All the best

Sergey

Andrey,

I missed (mea culpa) the fact that stdcall isn't applicable to em64t. Also, from the MKL FAQ (using MKL with IMSL) I learned that libguide and libguide40 are for static and dynamic linking, respectively, a fact that isn't explicitly stated in the ug.pdf.

Thanks,

Gerry

ps

Isn't item 5 in the using mkl and imsl entry of the FAQ redundant?

Sergey,

I just happened on this while snooping in the MKL FAQ.

Thanks,

Gerry

Leave a Comment

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