- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page