Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
6557 Discussions

How to get "mkl_core.dll" and mkl_intel_thread.dll ?

morita_tsu
Beginner
2,351 Views

Hello. I installed Intel® oneAPI Math Kernel Library on My Windows10 PC. Below is the URL I installed.
https://software.intel.com/content/www/us/en/develop/tools/oneapi/base-toolkit/download.html?

After finishing my installation, I couldn't find "mkl_core.dll" and mkl_intel_thread.dll in the "mkl" folder on My PC. Because I have to use them for my development. But I found "mkl_core.1.dll" and mkl_intel_thread.1.dll . I guess they are an updated version for "mkl_core.dll" and mkl_intel_thread.dll. Is that correct ? And Could you tell me how to get "mkl_core.dll" and mkl_intel_thread.dll ?

0 Kudos
24 Replies
Germán
New Contributor I
2,161 Views

I just installed that, too, a couple of days ago; the files you are looking for should be in c:\<installation-directory>\mkl\2021.3.0\lib\intel64

morita_tsu
Beginner
2,072 Views

"Thank you for replying. I found mkl_core_dll.lib and mkl_intel_thread_dll.lib in my folder you suggested. They are not "dll" files but "lib" files. I currently need to get the "dll" files. I think there are the "dll" files in c:\<installation-directory>\mkl\2021.3.0\redist\intel64. Unfortunatlly, I couldn't find mkl_core_dll and mkl_intel_thread_dll in the folder. Or do you mean I have to convert their "lib" files to "dll" files ? I heared we can convert that. I don't actually understand how to convert that..."

MRajesh_intel
Moderator
2,118 Views

Hi,


Can you please provide us a use case of how are you building your application with MKL (using cmd, visual studio)?


>> I guess they are an updated version for "mkl_core.dll" and mkl_intel_thread.dll. Is that correct ?


Please refer to this link for detailed information:

https://software.intel.com/content/www/us/en/develop/documentation/onemkl-windows-developer-guide/to...


Regards

Rajesh.




morita_tsu
Beginner
2,057 Views

Hello. Thank you for your comment. I don't actually know how to build the applications. I heard they are "bad" files and used visual studio.

I have to ask the developer about details.  I just try to use the applications. After executing, error dialogs about "mkl_core.dll"" and "mkl_intel_thread.dll" , are displayed.

mecej4
Black Belt
2,108 Views

The DLLs that you list, without ".1" in their names, such as "mkl_core.dll", pertain to the older Parallel Studio (2020  and earlier). If you are building with the OneAPI compiler and MKL products, you should not need those DLLs unless you are also linking to older libraries that require those older DLLs.

Please clarify why you think that mkl_core.dll, etc., are required.

morita_tsu
Beginner
2,060 Views

Thank you for your comment. I try to execute "bat" files using "mkl_core.dll"" and "mkl_intel_thread.dll". Unfortunately, I don't know some details about the "bat" files. Because I got the files from an other company.  I heard files were developed by  the visual studio.
When I executed those files, error dialogs that "mkl_core.dll" and "mkl_intel_thread.dll" are necessary, were displayed, respectively.
I think the files link to older libraries of "MKL" because of error dialogs - displays . As I try older libraries including those dll, I would be glad if I get older them.

As an other way, I renamed "mkl_core.1.dll" to "mkl_core.dll" ,and "mkl_intel_thread.1.dll" to "mkl_intel_thread.dll". I tried  to execute. I could execute some files but some files were crashed. By this result, I think some files need older libraries.

mecej4
Black Belt
2,036 Views

If you need the MKL DLLs only to enable you to run EXEs and DLLs provided to by a third party, rather than to build the EXEs and DLLs yourself, it should be sufficient to install the appropriate version of the Intel redistributables package. Ask the "other company" which Intel compiler they use, and choose the matching version of the redistributables.

Spencer_P_Intel
Employee
2,027 Views

Hi,

A little background information on windows shared (dynamic) libraries might do you some good here since there seems to be a little confusion as to what is what. (Of course there are many more details and the possibility to do things in many different ways, but what follows is a description of a common use case in windows libraries.)

The approach that Windows often takes for linking with shared (dynamically linked) libraries is different than the approach for Linux.  A shared library for Windows generally consists of two pieces:  (Lets focus on mkl_core lib for now, but it is similar for all the other shared libs as well)  When we build a shared library for mkl_core functionality, we end up with two libraries: mkl_core_dll.lib and mkl_core.dll  (it may have a .1.dll or .2.dll, etc to distinguish the different library versioning and compatibility). 

The first lib mkl_core_dll.lib is what we often refer to as the import library and is linked statically to the executable.  It's job is to let the executable know which APIs are available to be dynamically picked up from mkl_core.dll library and satisfy the linker step with names of apis. We store this mkl_core_dll.lib with the other static libs, for instance in the c:\<installation-directory>\mkl\2021.3.0\lib\intel64 folder.

The mkl_core.dll (or mkl_core.1.dll in some cases) is part of the redist (redistributables) package which @mecej4 provided the link for above.  An executable can build/link with the mkl_core_dll.lib a single time and then you can swap out different redist libs at runtime (as long as those different redist libs are compatible with the mkl_core_dll.lib import library.)  This is often a forward compatibility, meaning for instance you could build against MKL 2019.0 gold release and then you get ahold of MKL 2019 update 1 or 4 etc redist packages and instead of having to recompile, you can just swap out the redist libs for the new update and the executable should continue to work.  The place where you have to be careful (and may need to rebuild) is when crossing major release version where some functionality you are trying to use may have changed, but this is often more rare.  It is stored in the redist folder, for instance c:\<installation-directory>\mkl\2021.3.0\redist\intel64.

If you have the executable already, and are just looking to swap out the redist package, then you need to know which library the executable was built against and can use compatible redist libs.  

A final note, due to a change in our product from the MKL 2018, 2019, 2020 packages to the new oneMKL 2021 package, there was a change to the library versioning for the oneMKL 2021 product libraries (added the .1.dll and other internal changes) and so executables that were built against a pre-oneMKL 2021 library will need to be rebuilt to use the new oneMKL 2021 redist libraries.

Germán
New Contributor I
1,991 Views

Hi, Spencer:

What you are saying in one of your paragraphs does not sound quite correct to me.

 

You say:

The first lib mkl_core_dll.lib is what we often refer to as the import library and is linked statically to the executable. It's job is to let the executable know which APIs are available to be dynamically picked up from mkl_core.dll library and satisfy the linker step with names of apis. We store this mkl_core_dll.lib with the other static libs, for instance in the c:\<installation-directory>\mkl\2021.3.0\lib\intel64 folder.

 

But, no, the job of *.lib is not merely to let the executable know about APIs; in fact, the *.lib file is the entire (static) library to the point that the executable no longer even attempts/needs to read any dynamic *.dll library file.

 

If anything, the specification of the API comes from the header/include files *.mod, which would be needed at compile time of the program whether it is using the static or dynamic library.

 

Spencer_P_Intel
Employee
1,981 Views

Hi German,

Of course you are absolutely correct that the include files define the APIs and the *.lib library does contain the entire static library (commonly filled with stub functions and details how to load the appropriate relevant DLL function and run it) to fill the needs of the linker step.   I was simplifying a little too much here.  Thanks for clarifying that that paragraph was misleading.   

 

I guess to summarize, the real point of my original statement was that commonly there are two libraries generated for windows builds each of which have different roles and the swapping/exchanging of redist libs at runtime needs to be compatible with the *.lib libraries that were used to build the executable (which are in turn compatible with the headers/include files).  

mecej4
Black Belt
1,974 Views

Germán wrote: "...in fact, the *.lib file is the entire (static) library to the point that the executable no longer even attempts/needs to read any dynamic *.dll library file."

That is correct only for the MKL static libraries. It is not true for the MKL import libraries, which have "dll" in their names. Take, for example, the following pair:

 

 


03/12/2021  03:23 PM       664,009,344 mkl_core.lib
03/12/2021  03:23 PM         4,349,298 mkl_core_dll.lib

 

 

 

Only the first one, i.e., the  static library, contains the actual code for the MKL callable and internal routines. The second one does not, and the corresponding DLL is where the actual code resides. Given the size of MKL, there is no way that a 4 MB file can be a static library.

You can prove this for yourself by attempting to obtain the disassembly of a routine, for example, "pardiso", in mkl_core_dll.lib.

Germán
New Contributor I
1,931 Views


Hhhmmm...I guess I don't konw what I am talking about; and, I am thinking that there is something important I need to learn, here.

 

First of all, I have been a Linux kind of guy and having to switch to Windows as of a couple of months ago; second, I am not familiar with ifort, I just picked it up about a week ago.

 

For me, things have simply be *.a and *.so; and, so, I immediately jump to the one-to-one conclusion that things on the Windows side would simply be *.lib and *.dll.

 

But, I now realize that you are mentioning an additional file *dll.lib; sure enough, I was not aware of this one.

 

Not meaning to hijack this thread, how does a *dll.lib come about? Do I need to do something new, on purpose? I just brought a library of mine from Linux to Windows, built it to be dynamic library with ifort and I don't see the *dll.lib file.

 

Also, I guess I am going to have to learn about the redistributable stuff mentioned above...oh boy, welcome to Windows.

 

mecej4
Black Belt
1,917 Views

Don't worry, you just need a little bit of reading. In one sense, import libraries are an artifact of limitations in the capabilities of the MS linker. If you are an old Unix hand, you may remember ranlib. Its function was to generate an index and add it to an object archive. You can view a Windows import library as that index, placed into a separate file all by itself.

You can generate an import library knowing only the name of the library, the name of the DLL and the names of those symbols that you wish to "export".

In Fortran and Pascal we have interfaces and implementations. A DLL corresponds to a collection of implementations, and an import library to a collection of interfaces.

The Intel developers have added the string "dll" to the names of the MKL import libraries. This convention is neither necessary nor is it always followed.

Spencer_P_Intel writes with great clarity and understanding, but we cannot expect his responses in this forum to be complete treatises and to make up for lapses in the documentation.

Germán
New Contributor I
1,895 Views

Aha!...Got it. 

Thanks for all that. 

morita_tsu
Beginner
1,857 Views

Hello, mecej4. Thank you for your information. I installed  a redistributable library package of Parallel Studio XE 2019 on Redistributable Libraries for Intel® C++ and Fortran 2019 Compilers... . I got the compiler of a shared library. But I couldn't get "DLL" files like "mkl_core.1.dll" and mkl_intel_thread.1.dll.  I read the document but I don't understand.  What should I do except for installing  the redistributable library package ? 

mecej4
Black Belt
1,840 Views

Morita_tsu: In your first post of this thread, you said that you needed mkl_core.dll and mkl_intel_thread.dll. The redistributable package that you mentioned today is the correct package for those. What you wrote today does not match what you wrote then, in terms of which MKL DLLs you need.

As I wrote on Thursday,  ask the other company which Intel compiler they use, and choose the matching version of the redistributables.

morita_tsu
Beginner
1,827 Views

I made a mistake. I need mkl_core.dll and mkl_intel_thread.dll, as you wrote. I am in the middle of asking the company about "MKL".  I thought  there are old mkl_core.dll and mkl_intel_thread.dll in the redistributable package. But I didn't find them. What I would like to ask you  is , whether  I  can get old mkl_core.dll and mkl_intel_thread.dll if I install the redistributable package.  Do you mean the redistributable package includes mkl_core.dll and mkl_intel_thread.dll which were updated in a specific old  year like 2018, 2019  ? 

mecej4
Black Belt
1,824 Views

Yes, it is best if you know which version of the compiler was used by the company, so that you can download the matching redistributables.

Generally, newer MKL redistributables are compatible with objects compiled with older compilers. OneAPI is a new product.

Secondly, there is a dependence on VC DLLs, and Microsoft made significant changes around 2015 that broke forward compatibility.

MRajesh_intel
Moderator
1,755 Views

Hi,


Can you please let us know any updates regarding your query?


Regards

Rajesh.



MRajesh_intel
Moderator
1,711 Views

Hi,


We have not heard back from you, so we will close this inquiry now. If you need further assistance, please post a new question


Regards

Rajesh.


Reply