Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
7185 Discussions

Linking problem with MKL 10 under Visual C++

ediap
Beginner
770 Views
Hi!

I am a developer of the IT++ software library (http://itpp.sf.net/). IT++ can be linked to MKL to use it's BLAS/LAPACK and FFT routines.
I recently tried out the latest MKL 10 library for Windows (ia32 version). And I encountered problems with linking a few of the test programs included in the IT++ library. Here is an example build error message:

------ Build started: Project: vec_test, Configuration: Release Win32 ------
Linking...
mkl_core_dll.lib(_dgees_dyn.obj) : error LNK2005: _select_cdc_dgees1 already defined in mkl_intel_c_dll.lib(_dgees_dll.obj)
mkl_core_dll.lib(_zgees_dyn.obj) : error LNK2005: _select_cdc_zgees1 already defined in mkl_intel_c_dll.lib(_zgees_dll.obj)
D:msyshomeediapitpp-4.0.1_pre20071213win32itpp_mkl_tests\..invec_test.exe : fatal error LNK1169: one or more multiply defined symbols found
Build log was saved at "file://d:msyshomeediapitpp-4.0.1_pre20071213win32itpp_mkl_testsvec_test_buildReleaseBuildLog.htm"
vec_test - 3 error(s), 0 warning(s)

For linking, I am using a wrapper DLL library "mkl_c_dll.lib" and multi-threaded DLL linking. The same test programs compile and link fine using older MKL releases - I tried 9.1 and 8.1.
A workaround for this problem is to use static linking for these tests, i.e. link to "mkl_c.lib libguide40.lib", but this is not a good solution for me.
So I suspect that there is a bug in the latest MKL release.

Anyone can confirm similar problems?
BR,
/Adam
0 Kudos
4 Replies
TimP
Honored Contributor III
770 Views
If you read the forum, you would see that MKL 10 is different from its predecessors, Also you would see
that you must consult the documentation, even if it (the documentation) may be considered buggy.
Generally, you use either one of the packages which aren't real libraries but invoke typical combinations (e.g. mkl_c..), or you use
the actual "layered" libraries, such as the thread and the core libraries.
0 Kudos
ediap
Beginner
770 Views
Hi Tim,

Thanks for your interest!
I have already read the documentation carefully and also searched the forum threads. And I definitely know the new linking layered model of MKL 10.

Anyway, the problem occurs only on Windows with MSVC++ .NET using dynamic linking. I have no problems linking these particular test programs to static libraries (both dummy and pure layered ones) and also no problems with linking to MKL 10 under Linux (where both static and shared linking works fine).

I tried the dummy DLL library first (i.e. mkl_c_dll.lib) because it would provide me the compatibility with MKL 8 and 9, but I also tried the libraries from pure layered model, i.e.:
"mkl_intel_c_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib"
In both cases the linker says that "_select_cdc_dgeesl" is already defined:
mkl_core_dll.lib(_dgees_dyn.obj) : error LNK2005: _select_cdc_dgeesl already defined in mkl_intel_c_dll.lib(_dgees_dll.lib)

So, it seems that the interface layer (mkl_intel_c_dll.lib) is incompatible with the computational_layer (mkl_core_dll.lib) here.
Therefore, I still suspect the problem is in MKL itself, not the linking options I use.

If you think I am doing something wrong, I would be glad to hear about this. Thanks in advance!

BR,
/Adam
0 Kudos
TimP
Honored Contributor III
770 Views
Both my reading of the docs and your error messages point to the conclusion that mkl_c libraries aren't intended to work in the layered model. Do you get undefined references if you use just the other 2 libraries, or, intead, the mkl_lapack or fft and mkl_c?

0 Kudos
ediap
Beginner
770 Views
But I do not try to use the "mkl_c.lib" (the dummy static one), but "mkl_c_dll.lib" (the dummy DLL library), because I am interested in dynamic linking. As I previously said, the static linking works fine.

So, to be precise, these combinations of static libraries work fine with MKL 10:
1) "mkl_c.lib"
2) "mkl_intel_c.lib mkl_sequential.lib mkl_core.lib"
3) "mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libguide.lib"

According to the documentation 1) is adequate to 3), since mkl_c.lib is a dummy wrapper of 3).

But these combinations of dynamic libraries result in the linking errors quoted in my previous email:
1)
"mkl_c_dll.lib"
2) "mkl_intel_c_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib"
3) "mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libguide40.lib"


When I try with only two latter libraries, e.g.: "mkl_sequential_dll.lib mkl_core_dll.lib" I got a lot of unresolved symbols of BLAS functions, because I did not specified the interface library:

Linking...
itpp.lib(mat.obj) : error LNK2001: unresolved external symbol _zcopy_
itpp.lib(schur.obj) : error LNK2001: unresolved external symbol _zcopy_
[...]

As I said at the beginning, I have no problems linking these three test programs to a static "mkl_c.lib", no matter if I use "mkl_lapack.lib" or "mkl_cdft.lib" or not, since this is static linking.

I would be glad if you could download the latest stable IT++ library sources from http://itpp.sourceforge.net/ and build the IT++ library linked to MKL (just use win32/itpp_mkl.vcproj in MSVC++ and set target to Release). Then you can try to link the test programs to the IT++ library. Just use win32/itpp_mkl_tests/array_test.vcpoj) and build the whole solution. You will see that 3 out of 52 tests will result in the linking errors I reported in my initial email of this thread.

BR,
/Adam

0 Kudos
Reply