static linking 11.3, mkl_tbb_thread : mismatch detected for '_MSC_VER'

[Essex_E_]

I'm building a DLL as a plugin for Autodesk Maya. I'm trying to statically link MKL into my DLL and having some difficulty. I'm using Visual Studio 2013 as IDE and its default platform toolset (v120). I'm not using the Intel Visual Studio integration, because it doesn't seem to offer a static-linking option.

With Parallel Studio 11.2, I didn't have any difficulty. Static linking works fine. With 11.3 update 3, when I link to mkl_intel_thread.lib, it still works fine. However, when I link with mkl_tbb_thread.lib instead, linking fails with the following error:

mkl_tbb_thread.lib(lnnt_omp_tbb_lp64.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1800' in PardisoTest.obj

mkl_tbb_thread.lib(lnnt_omp_tbb.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1800' in PardisoTest.obj

I'll point out that 1800 is the MSVC compiler version that I'm using. 1600 is the Visual Studio 2010 compiler, and I'm surprised to see it here.

My entire linker arguments are:

/OUT:"C:\ziva\dev\Spikes\PardisoTest\x64\Release\PardisoTest.exe" /MANIFEST /LTCG /NXCOMPAT /PDB:"C:\ziva\dev\Spikes\PardisoTest\x64\Release\PardisoTest.pdb" /DYNAMICBASE "freeglut.lib" "opengl32.lib" "glew32.lib" "mkl_core.lib" "mkl_tbb_thread.lib" "mkl_intel_lp64.lib" "tbb.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X64 /OPT:REF /INCREMENTAL:NO /PGD:"C:\ziva\dev\Spikes\PardisoTest\x64\Release\PardisoTest.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\PardisoTest.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\tbb\lib\intel64_win\vc12" /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\lib\intel64_win" /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\compiler\lib\intel64_win" /TLBID:1 

I'm not sure what to do with this. There's only one mkl_tbb_thread.lib file, so it's not like I am linking with the wrong one.

Thank you for any help you can provide,

-Essex

[Essex_E_]

Correction: I cannot statically link 11.3u3 when using mkl_intel_thread either. On my simple test program, it worked, but in my larger application, linking fails with:

libcpmt.lib(xlocale.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in AxolotlTests.obj
libcpmt.lib(xlocale.obj) : error LNK2005: "public: __cdecl std::locale::id::id(unsigned __int64)" (??0id@locale@std@@QEAA@_K@Z) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "public: __cdecl std::locale::id::operator unsigned __int64(void)" (??Bid@locale@std@@QEAA_KXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "protected: char * __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::_Gninc(void)" (?_Gninc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@IEAAPEADXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "protected: char * __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::_Pninc(void)" (?_Pninc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@IEAAPEADXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "public: int __cdecl std::ios_base::flags(void)const " (?flags@ios_base@std@@QEBAHXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "protected: char * __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::gptr(void)const " (?gptr@?$basic_streambuf@DU?$char_traits@D@std@@@std@@IEBAPEADXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "public: int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sbumpc(void)" (?sbumpc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QEAAHXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "public: int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sgetc(void)" (?sgetc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QEAAHXZ) already defined in msvcprt.lib(MSVCP120.dll)
libcpmt.lib(xlocale.obj) : error LNK2005: "public: int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sputc(char)" (?sputc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QEAAHD@Z) already defined in msvcprt.lib(MSVCP120.dll)
l

...

...

...

I want to statically link.  I'm using MD code generation, because I'm building a DLL. But, it looks like something from MKL is dragging in the MT standard library?

[Evgueni_P_Intel]

Hi Essex E.,

The first issue is a bug in MKL which is expected to be fixed in MKL 11.3 update 4 and in MKL 2017 beta update 1.

To work-around it, you may add '-D_ALLOW_MSC_VER_MISMATCH -D_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH' to the compile line to disable MSVS version checks.

I am looking into the second issue and will reply soon.

Evgueni.

[Evgueni_P_Intel]

The second issue does not seem to be related to MKL.

The error messages indicate that you mix the static version of the C runtime library, libcmt.lib, with the dynamic version, msvcrt.lib.

You should use one or other but not both.

[Essex_E_]

Are there no correctness concerns to using _ALLOW_MSC_VER_MISMATCH and _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH?

I'm not convinced that the second issue isn't related to MKL. I will try to make a standalone test case that I can share. So far, I've observed that linking succeeds if I comment out uses of MKL in my code and stop linking against it. The linker error also goes away if I switch the library order during linking to:

mkl_core.lib;mkl_intel_thread.lib;libiomp5md.lib;mkl_intel_lp64.lib;tbb.lib;

The following orders, for example, generate the above MT/MD linker error.

mkl_intel_lp64.lib;mkl_core.lib;mkl_intel_thread.lib;libiomp5md.lib;tbb.lib;

tbb.lib;mkl_intel_lp64.lib;mkl_core.lib;mkl_intel_thread.lib;libiomp5md.lib;

mkl_intel_lp64.lib;mkl_intel_thread.lib;mkl_core.lib;libiomp5md.lib;tbb.lib;

[Ying_H_Intel]

Hi Essex, 

Thanks for trying it out.

May you please  try  use the /NODEFAULTLIB:libcpmt.lib linker option  to solve the second question? 

About your DLL build, is the tbb.lib required in your code?  if remove it. the link order will generate different result? 

could you please show the result of Dependency worker  like the figure 1 in https://software.intel.com/en-us/articles/some-more-additional-tips-how-to-call-mkl-from-your-c-code/? 

( I ask it, just guess if there are tbb or openmp library existing both in Autodesk Maya and in your DLL). 

Best Regards,

Ying

[Essex_E_]

Unless otherwise specified, everything below assumed a building that's linking with intel_mkl_thread.lib.

/NODEFAULTLIB:libcpmt.lib resolved the error: "mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease'" .  With the /NODEFAULTLIB:libcpmt.lib flag, I can specify the mkl/tbb libraries in one of the orders that didn't work before.  Thanks :)

Dependency Walker on my DLL says: https://drive.google.com/file/d/0B1-EScYNsy0ucWJBenNyRXJxbFU/view?usp=sharing.

Removing tbb.lib from the link line, everything still builds fine (both my DLL and standalone Executable with unit tests). Dependency Walker output is the same, so something else seems to be dragging in tbb.dll. Nothing about tbb appears on my link line.

I still haven't been able to link against mkl_tbb_thread.lib. The previous suggestion to use _ALLOW_MSC_VER_MISMATCH did not resolve the problem for me. I'm not sure where, but some other library I'm using must be also be exporting MSC_VER stuff.  I haven't been able to give this much attention lately, since I had to ship a release I just went ahead with mkl_intel_thread.lib and the particular lib order I found that worked.  Since it's supposed to be fixed in MKL 11.3 update 4, can you tell me when that's supposed to come out?

[Essex_E_]

Regarding MSC_VER, compiling with _ALLOW_MSC_VER_MISMATCH defined, I still can't link with error message:

msvcprt.lib(newaop_s.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1800' doesn't match value '1600' in mkl_tbb_thread.lib(lnnt_omp_tbb_lp64.obj)

Visual Studio's C++ standard library comes as a binary msvcprt.lib with MSC_VER=1800 defined in it. MKL's mkl_tbb_thread.lib has MSC_VER=1600 defined in it. Adding a compile-time preprocessor symbol (_ALLOW_MSC_VER_MISMATCH) when compiling my own code didn't stop those from clashing.

[Ying_H_Intel]

Hi Essex, 

Nice to know the result.

As tbb thread or OpenMP thread are independent each other,  ether OpenMP thread  ( mkl_intel_thread.lib, which is for OpenMP)  or TBB thread (mkl_tbb_thread.lib)  is enough for one application.   So it should fine  you  to ship your product with OpenMP thread for now.  

If for tbb thread, next version (may be update 4 or 2017 golad) was planed to target in late of Q3. We will announce it in the forum by that time

Regarding the tbb.lib, there are two kind of tbb,  one is static library tbb.lib,  another may be dll's import library, same name tbb.lib

from the output of  dependency walking, the tbb.dll seems from autodesk Maya 's bin folder.   After you remove the tbb.lib, is it still there? 

could you please open your MSVC project property => linker => show the progress to see how the tbb was linked to the program. 

Best Regards,

Ying 

[Essex_E_]

Yes, tbb.dll shows up in Dependency Walker independent of whether or not I have tbb.lib in my link line.

I was under the impression that tbb.lib is not really (much) of a static library. Doesn't it just cause the program depend on and load tbb.dll at run time? Is there actually a non-trivial amount of code in tbb.lib?

I don't understand what you're asking for with the linker "show the progress" option. What would you like to see, and for which build configuration? In my own quick trial with "show progress" on, the TBB shows up in two spots. First, at the beginning of linking:

  Starting pass 1
  Processed /DEFAULTLIB:msvcprt
  Processed /DEFAULTLIB:tbb.lib
  Processed /DEFAULTLIB:uuid.lib
  Processed /DEFAULTLIB:MSVCRT
  Processed /DEFAULTLIB:OLDNAMES

Then, eventually,

        Found MSVCP120_NULL_THUNK_DATA
          Referenced in msvcprt.lib(MSVCP120.dll)
          Loaded msvcprt.lib(MSVCP120.dll)
LINK : fatal error LNK1104: cannot open file 'tbb.lib'

Linking fails this time because I've removed the path to tbb.lib from my library path.  Neither of these mentions of tbb explain which object file is adding tbb.lib as a DEFAULTLIB.

The link line in this test is:

/OUT:"C:\ziva\dev\Spikes\PardisoCrash\x64\Release\PardisoCrash.exe" /MANIFEST /LTCG /NXCOMPAT /PDB:"C:\ziva\dev\Spikes\PardisoCrash\x64\Release\PardisoCrash.pdb" /DYNAMICBASE "mkl_core.lib" "mkl_intel_thread.lib" "libiomp5md.lib" "mkl_intel_lp64.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X64 /NODEFAULTLIB:"libcpmt.lib" /OPT:REF /INCREMENTAL:NO /PGD:"C:\ziva\dev\Spikes\PardisoCrash\x64\Release\PardisoCrash.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\PardisoCrash.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /VERBOSE /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\lib\intel64_win" /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\compiler\lib\intel64_win" /TLBID:1 

Is there something that you're looking for or concerned about?  My situation seems resolved:

1) With mkl_intel_thread.lib, everything is working for me with and I have no more problems with it. 

2) With mkl_tbb_thread.lib, it doesn't link and won't ever link for me, because it includes MSC_VER_MISMATCH checks that can't be ignored. My only options here are to wait for the next update, or hex-edit the binary mkl_tbb_thread.lib file myself.

[Gennady_F_Intel]

Essex, pls try to take the latest 11.3 update 4 and check if the linking problem you reported, is still there on your side. thanks.

[Essex_E_]

I upgraded to 11.3 update 4, and this linking problem has been resolved. Thanks.

[Ying_H_Intel]

Hi Essex, 

Thank you much for the news.  Glad to know the issue was resolved. in update 4 

Thanks

Ying