I just installed Parallel Studio 2013 initial release and I am not happy.
I am trying to build one of my projects which uses the following IPP functions:
From what I understand, those are not threaded which is fine by me.
Also, from what I understand, Intel engineers want to remove multi-threaded IPP in favor of threading on the application level which is also fine by me.
To avoid deprecation I switch my build to use single-threaded static IPP.
I think to myself "Great, now I will be able to create standalone DLL with no dependencies." (which is good for this project because it is a dynamically loaded video processing plugin for VirtualDub and it is desirable not to have any dependencies for the ease of distribution), and I also switch the compiler to /MT to use static multi-threaded runtime.
Note that the project is using OpenMP.
Now that you have a complete picture, please tell me what the hell are references to libiomp5md.dll doing in my DLL?
Not only your engineers have removed libiomp5mt.lib (which I reported in a still open and long unresolved issue #673583) from the Parallel Studio 2013, but they go so far that they are now faking successfull multi-threaded static compilation while doing completely different and sneaky thing behind the scenes from what I asked them to do by setting an option in Visual Studio GUI?
Seriously, where does the deceit of a fellow developer end nowadays? What the hell? Is that behavior documented anywhere? Does Parallel Studio 2013 Readme or Release Notes say "Note that if you select /MT you will still get dynamically linked runtime because you don't know what you are doing and we know better"?
I am well aware that static OpenMP runtime can cause issues, but how am I supposed to build a standalone executable now?
More important, why do I have to distribute 31.4MB runtime for a 500KB plugin? What are my alternatives to that nonsense?
Finally, libiomp5md.dll contains text references for the following DLL files:
Some of those don't even exist in the compiler redist folder and the others most likely reference some other DLLs in turn. Given the possibility of dynamic linkage and delayed loading, how am I supposed to know which ones should be distributed alongside with my application?
Does it have to be this messy?