1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __malloc_dbg already defined in MSVCRTD.lib(MSVCR100D.dll)
1>LIBCMTD.lib(sprintf.obj) : error LNK2005: _sprintf already defined in MSVCRTD.lib(MSVCR100D.dll)
1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: _exit already defined in MSVCRTD.lib(MSVCR100D.dll)
These are the libs I added as described in manual:
However with non-multithreaded static linkage without libiomp5mt.lib all compiles perfectly
Why you are linking to different versions of same library? ex: ippcc you are doing a static linkage with dispatching as well as static linkage without dispatching !!
Please refer to IPP linkage models and choose the one that suites your application version.
It looks like you've got a conflict between the Microsoft C runtime libraries and the Intel compiler C runtime libraries (libirc.lib is the Intel C runtime libraries). I believe the OpenMP library calls many of the C runtime functions being referenced in your error messages.
Based on the information you give above, it is not clear exactly what is causing this problem. What happens if you remove libirc.lib from the link list? Also, please try this with libiomp5md.lib, rather than libiomp5mt.lib.
Static Linkage with Dispatching
To use the static linking libraries, you need link to ipp*emerged.lib, ipp*merged.lib,
ippsemerged.lib, ippsmerged.lib, and ippcorel.lib.
If you want to use the Intel IPP functions threaded with the OpenMP*, you need link to
ipp*emerged.lib, ipp*merged_t.lib, ippsemerged.lib, ippsmerged_t.lib,
ippcore_t.lib, and additionally libiomp.lib.
For example, your application uses three Intel IPP functions ippiCopy_8u_C1R,
ippiCanny_16s8u_C1R and ippmMul_mc_32f. These three functions belong to the image
processing, computer vision, and small matrix operations domains respectively. If you
want to use the threaded functions, you must link the following libraries to your
ippcvemerged.lib and ippcvmerged_t.lib
ippmemerged.lib and ippmmerged_t.lib
ippiemerged.lib and ippimerged_t.lib
ippsemerged.lib and ippsmerged_t.lib
So I added those ipp*emerged.lib and ipp*merged.lib libraries
What is the discrepancy with the manual?
Also there is no libiomp5.lib present, only libiomp5d.lib and libiomp5t.lib.
What is the difference between the two?
With libiomp5md.lib everything is linked correctly but libiomp5md.dll is linked to the application.
libirc.lib is needed by libiomp5m*.lib as it contains fast mem copying which are used in libiomp. Without libirc.lib there are corresponding unresolved.
It is natural to include libiomp5mt.lib for static linkage since application will get rid of dll dependencies
The file named "libiomp5md.lib" is the dynamic lib version of the Intel OpenMP library and the one named "libiomp5mt.lib" is the static version of the OpenMP library.
The static version of the OpenMP library has been "deprecated" and you are encouraged to only use the dynamic version of the library, even if your application is linked statically to the IPP library. This is due to the problems associated with managing a single set of hardware thread resources from multiple instances of a library... If you know for a fact that the static instance of OpenMP linkedto your application will be the only one present on the system, when your application runs, you should not experience any issues. If another application runs simultaneously as yours, and is also using OpenMP (or something similar) you may see some performance degradation. This is simply due to competition for limited hardware resources. When both application share the same OpenMP DLL they will run cooperatively. You may still see a degradation, due to sharing between the two apps, but the performance decrease will likely be less noticeable, if at all.
For general linking issues, please review this article:
Simplified Link Instructions for the IPP Library
which provides a "brute force" method for linking. The manual tries to suggest that you use the minimum list of library files when linking. However, the linker is smart enough to only include that which you need, so the article above takes the approach of including everything, and letting the linker figure it out. Won't result in a larger application.
Note that in the 7.0 release of the IPP library this "brute force" method is built-in using some compiler pragmas. The "simplified link instructions" article will be updated to reflect that change.