Depending on some compiler flags (which I'm not totally sure which ones are triggering) I get a Intel DLL dependency for my project to:
My project is a /MD compiled DLL with some tights algorithms where I would like to use auto-parallelization and PGO. I would prefer to statically link everything into our DLL, to avoid having to distribute any further DLLs.
I was able to get rid of the svml_dispmd.dll reference by explicitly including: svml_disp.lib but I'm not sure if this is OK or not?
Is there any way to link the Intel provided libraries statically? Especially the MKL?
- Development Tools
- Intel® C++ Compiler
- Intel® Parallel Studio XE
- Intel® System Studio
- Parallel Computing
libiomp5md.dll is an OpenMP runtime library. You could get it linked with your DLL by using /Qopenmp or /Qparallel compiler options.
There is no static libiomp5 on Windows.
There is no general way to link Intel libraries statically on Windows (on Linux/MacOS you can use -static-intel option)
As for linking MKL libraries you can find related information in the documentation - https://software.intel.com/en-us/mkl-windows-developer-guide-linking-your-application-with-the-intel...
Thanks for the clarification.
For us the non-static-only on Windows is a massive disadvantage of the Intel compiler tools. I really don't get why it's done. Maintenance, deployment, and distribution must be as simple as possible. The fewer parts the better.
But there is a custom DLL build tool. And I think they have to compile it from some pre-compiled libs/object files. Wouldn't it be possible to use these?
Before deciding to build a static OpenMP runtime and link it into your code you need to understand why we don;t distribute one (which isnot just to make your life harder!).
The reason is that statically linking an OpenMP runtime library into another library is a very bad idea, since it can easily cause extremely poor performance and, potentially, unreported correctness problems.
This can happen if your library is linked into a process where some other component also uses OpenMP. In that case there will be two OpenMP runtime libraries in the process. When that happens
- Each runtime library will create its own thread pool, leading to over-subscription (creation of many more threads than there are hardware "logical CPUs" to execute them). This, in turn, leads to very poor performance as the threads contend for the available hardware.
- If you share data between your code and the other components, and assume that updating it inside a critical section will provide atomicity, you will now be disappointed. Each OpenMP runtime will have its own internal set of locks for implementing critical sections, and there will be no mutual exclusion between the different libraries, which could lead to silent wrong answers.
Much better is simply to ship a copy of the runtime dynamic library with your code. That way you won't force two runtimes into the process and won't have these problems.
(We looked long and hard for a solution to this, but haven't managed to find one. This is just something you really shouldn't do, so we make it hard for you to do it).
Note, too, that this is one of the reasons why we provide libgomp compatible interfaces, so that you don't have to have two OpenMP runtimes in your process if you mix GCC compiled and Intel (or CLANG) compiled OpenMP code.
Mixing runtimes (which is likely as soon as you statically link an OpenMp runtime) is just A BAD IDEA.
I'm aware of the "double run-time" problem. The same applies to DLL & EXEs if the link against the static C run-time library. You would end up with two versions of it and things like file-handles etc. can't be shared etc.
The thing is, I know that I won't end up with two copies of the run-time in our case. But still, I can't do it. I can understand that you don't want to get thousand support requests from people not understanding what they are doing. However, there should be a, can be pretty hidden, way to do it anyway.
So, is there a non-standard way of getting it linked statically?