Optimization Solver - Unresolved Symbols

[Intel_C_Intel]

Hello,

I am trying to use the optimization solver (nonlinear least sq without constraints) from Managed C++ in VS 2005 and get these linker errors:

******************

1>mkl_solver.lib(d_tr_trialstep_nlsqp_withMP.obj) : error LNK2019: unresolved external symbol _mkl_lapack_dpotrs referenced in function _dmintr_ls_pd_withmp
1>mkl_solver.lib(d_tr_trialstep_nlsqp_withoutMP.obj) : error LNK2001: unresolved external symbol _mkl_lapack_dpotrs
1>mkl_solver.lib(d_tr_trialstep_bc_subP_withMP.obj) : error LNK2001: unresolved external symbol _mkl_lapack_dpotrs
1>mkl_solver.lib(d_tr_trialstep_bc_subP_withoutMP.obj) : error LNK2001: unresolved external symbol _mkl_lapack_dpotrs
1>mkl_solver.lib(d_tr_trialstep_nlsqp_withMP.obj) : error LNK2019: unresolved external symbol _mkl_lapack_dtrtrs referenced in function _dmintr_ls_pd_withmp
1>mkl_solver.lib(d_tr_trialstep_nlsqp_withoutMP.obj) : error LNK2001: unresolved external symbol _mkl_lapack_dtrtrs
1>mkl_solver.lib(d_tr_trialstep_bc_subP_withMP.obj) : error LNK2001: unresolved external symbol _mkl_lapack_dtrtrs
1>mkl_solver.lib(d_tr_trialstep_bc_subP_withoutMP.obj) : error LNK2001: unresolved external symbol _mkl_lapack_dtrtrs
1>mkl_solver.lib(d_tr_trialstep_utils.obj) : error LNK2019: unresolved external symbol _mkl_blas_dasum referenced in function _dgrgbound


**************************

I am currently linking with mkl_c_dll.lib and libguide40.lib and mkl_solver.lib

When I link with mkl_c.lib and libguide.lib the errors go away.
Is this because there is no mkl_solver_dll.lib ?

If yes, is there a way to obtain the dll version of the solver lib ?

Thank you.
vikrantca

[Sergey_G_Intel]

DearVikrantca,

Unfortunately, MKL does not have DLL solver library for performance reasons. Therefore, it is impossible to obtainDLL version of the solver library. Please use the combination mkl_c.lib and libguide.lib that is working.

If it really matters to you, you can submit a request for DLL version of solver library. Please provide reasons for the request as MKL engineers need to understand the problem.

Kind regards,

Sergey

[vikrantca]

Sergey, Thanks for the reply.
We dont have any specific need for the dll version. But I have a couple of naive questions -

1. When we link to the static library, are the processor specific kernels still loaded for computations ?
2. Do I still need to distribute ALL the DLL's ? If not, then how is the processor specific code executed ?

Thanks a lot.

vikrantca

[Intel_C_Intel]

While there are no indications about runtime selection in the naming of the static libraries, they have multiple instances of key functions inside, effecting the same kind of code selection that occurs with dlls. If you use a tool like nm (either in Linux or with some Linux emulation tool on Windows, such as MKS NT) and use it on, for instance, mkl_ia32.lib and grep for dgemm, you will see calls to mkl_blas_def_dgemm, mkl_blas_p3_dgemm, mkl_blas_p4_dgemm, mkl_blas_p4m_dgemm, mkl_blas_p4p_dgemm. Each of these represents a different architecture which then calls processor-specific code in the library. Thus, there are multiple versions of the various functions.

If you look at all the output from nm when filtered through grep for dgemm, you will see that there are lots of processor specific functions that get executed as selected at runtime.

Bruce

[Sergey_G_Intel]

Dear Vikrantca,

Processor specific kernels are always loaded for computations. It does not matterwhether you link dynamic or static library.

I'm not sure that I understand your second question correctly. What do you mean by distributing of DLL's? If you link static libraries, you need no dynamic libraries at all. All the processor specific kernels are contained in static (as well as dynamic) libraries. The only difference is that static librarylinks all the kernels to the program, while dynamic does not need to do this as it may select proper kernel at a run-time. That is why statically linked libraries increase the size of executables.