Help with C call of dgesv in Visual Studio 2005

[eeweh]

I am a fortran guy and I'm trying to learn how to use C, so I can use Nvidia's CUDA.

So, I have been trying to write a code in C that will solve Ax=b.

When I try to compile the file, everything is OK, but when I try to build the solution, it gives me all sorts of unresolved externals. For example, here are a couple of the errors:

Error8error LNK2019: unresolved external symbol ___kmpc_global_thread_num referenced in function _mkl_lapack_dgetrfmkl_intel_thread.lib
Error9error LNK2001: unresolved external symbol ___kmpc_global_thread_nummkl_intel_thread.lib
Error10error LNK2001: unresolved external symbol ___kmpc_global_thread_nummkl_intel_thread.lib
Error11error LNK2001: unresolved external symbol ___kmpc_global_thread_nummkl_intel_thread.lib
Error12error LNK2019: unresolved external symbol ___kmpc_dispatch_init_4 referenced in function L__mkl_lapack_dgetrf_306__par_loop1mkl_intel_thread.lib

The file is mkl_thread_lib

I don't know where my problem is, but I know I must not be doing something correct.

Here is essentially part of my matrix equation showing column major format and my call to dgesv:

matfor[ ((j-1)*(numnode)) + (i-1)] = n * 4. * (n - 1.) * (r1 * r1 + r2 * r2) * pow(d1, d2) / (r6 * r6) + n * 4. * pow(d3, d4) / (r10 * r10);

dgesv (&numnode, &nrhs, matfor, &numnode, ipvt, rhs, &numnode, &info); // ipvt, matfor, andrhs are already pointers, I don't need the & when I call it.

up at the header section I've included:

#include

"mkl.h"

//void DGESV( MKL_INT *n, MKL_INT *nrhs, double *a, MKL_INT *lda, MKL_INT *ipiv, double *b, MKL_INT *ldb, MKL_INT *info );

In Project Property -> Linker -> Input -> AdditionalDependancies I've put mkl_s.lib mkl_lapack.lib

In Project Property -> Linker -> General -> Additional Library Directories I've put C:Program FilesIntelMKL10.0.3.021ia32lib

I think I've added the directories for the include files, the library files and the executable files too.

I think my program is OK, and I think it is able to see dgesv and make the appropriate connection from my program to dgesv, but somewhere in dgesv I think it is having trouble finding all the kmpc stuff.

EDIT: I should have said I'm using Windows Vista as the OS in case that makes any difference.

Any ideas on how to fix this problem. Thanks very much. Sincerely,

Elliott

[Todd_R_Intel]

Thanks Ben. I expect that to solve the problem as the unresolved references are threading functions and libguide.lib one of the OpenMP threading runtime library options available.

Using libiomp5mt.libmight be a better option though. It will support use of OpenMP threading in your app compiled with VS2005 whereas libguide.lib will not. Check out the user guide (docs online) for more information.

-Todd

[eeweh]

Thanks very much guys. I haven't seen yet if I got the expected results, but it compiled and built and didn't give me any linking problems. Thanks so much.

Does it say somewhere in the userguide what libs you need to add for the particular routines that you're going to call?

Elliott

[Todd_R_Intel]

The libraries you link are not dependent on the routines called so much as on a few other factors like compiler, interface, and threading model. The exceptions with the current release (10.0 update 3) are the sparse solvers, ScaLAPACK, and the cluster FFTs. But, its best not to guess on any of this based on filenames. Better to check out the User Guide (in the doc directory or online) where all the libraries are described, linking is discussed, and example provided.
-Todd

[TimP]

About libiomp5:

It's compatible with VC9 -openmp (VS2008), so you could have a combined build using any combination of VC9 OpenMP, Intel C or Fortran OpenMP, and mkl_thread. Apparently,libiomp5 wouldbecome the default OpenMP library for the next major release of Intel C++ and Fortran (using /Qopenmp). I don't know that VS2005includes any OpenMP, so you may as well start using libiomp5so as toavoid future changes.

When MKL 10 was first introduced, there was a tendency to recommend libguide even when you didn't need"legacy" Intelcompatibility, but that recommendation seems to have changed.