[SOLVED] compile mex with blas under windows

Hello, I need to compile c mex file under windows. Under Ubuntu it works fine if

mex -v sparseQPsetup.c CFLAGS="\$CFLAGS -O2 -Wall -pedantic" -lblas -std=c99

Under windows I tried

mex -v sparseQPsetup.c libmwblas.lib

with result

 Writing library for sparseQPsetup.mexw32 
c:\docume~1\pavel\locals~1\temp\mex_pi~1\sparseqpsetup.obj .text: undefined reference to '_dgemv_' 
c:\docume~1\pavel\locals~1\temp\mex_pi~1\sparseqpsetup.obj .text: undefined reference to '_dgemm_' 

C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Link of 'sparseQPsetup.mexw32' failed. 

??? Error using ==> mex at 218
Unable to complete successfully.

Usually it works but in this case I use some code when I'm calling

F77_CALL(dgemv)(&nontrans,&nx,&nx,&done,A,&nx,x,&ione,&dzero,dptr,&ione);

instead of

dgemv(&nontrans,&nx,&nx,&done,A,&nx,x,&ione,&dzero,dptr,&ione);

Header file is written in this style

#define F77_CALL(x)  x ## _

#define F77_NAME(x)  F77_CALL(x)

#ifdef  __cplusplus

extern "C" {
#endif

/* Level 2 BLAS */

extern void   F77_NAME(dgbmv)(const char *trans, const int *m, const int *n,
                              const int *kl,const int *ku, const double *alpha,
                              const double *a, const int *lda, const double *x,
                              const int *incx, const double *beta, double *y,
                              const int *incy);

extern void   F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
                              const double *alpha, const double *a,
                              const int *lda, const double *x, const int *incx,
                              const double *beta, double *y, const int *incy);...

Please correct me what I'm doing wrong...

Answer 1

[James Tursa]

Drop the trailing underscore _ on Windows. E.g.,

#define F77_CALL(x)  x ## _

puts a trailing underscore on the BLAS library name. Don't do this on Windows. Try this instead:

#if defined(__OS2__) || defined(__WINDOWS__) || defined(WIN32) || defined(_WIN32) || defined(WIN64) || defined(_WIN64) || defined(_MSC_VER)
#define F77_CALL(x)  x
#else
#define F77_CALL(x)  x ## _
#endif

Also, you shouldn't be using int for the integer types in the BLAS/LAPACK signatures. You should be using mwSignedIndex instead. E.g.,

extern void   F77_NAME(dgbmv)(const char *trans, const mwSignedIndex *m, const mwSignedIndex *n,
                              const mwSignedIndex *kl,const mwSignedIndex *ku, const double *alpha,
                              const double *a, const mwSignedIndex *lda, const double *x,
                              const mwSignedIndex *incx, const double *beta, double *y,
                              const mwSignedIndex *incy);

extern void   F77_NAME(dgemv)(const char *trans, const mwSignedIndex *m, const mwSignedIndex *n,
                              const double *alpha, const double *a,
                              const mwSignedIndex *lda, const double *x, const mwSignedIndex *incx,
                              const double *beta, double *y, const mwSignedIndex *incy);...

Answer 2

[Geoff]

Did you not try:

mex -v sparseQPsetup.c -lmwblas

[Pavel]

it gives same result

Answer 3

[Pavel]

good point! It almost works...one underscore lefts

 Writing library for sparseQPsetup.mexw32 

 c:\docume~1\pavel\locals~1\temp\mex_fr~1\sparseqpsetup.obj .text: undefined reference to '_dgemv' 
 c:\docume~1\pavel\locals~1\temp\mex_fr~1\sparseqpsetup.obj .text: undefined reference to '_dgemm'

[James Tursa]

That means it is not linking in the BLAS library. What version of MATLAB are you running? Earlier versions had the BLAS & LAPACK libraries in one library file, the libmwlapack.lib. Later versions split it out into libmwblas.lib and libmwlapack.lib. You could try the -l option as Geoff suggests, or include the full path name of the library on the mex command line itself (that is what I usually do), or even copy the library file to your local directory and then just list the lib name.

[James Tursa]

P.S., The leading underscore is normal and is expected to be there, as it is part of the actual exported function name as seen by the linker.

Answer 4

[Pavel]

Yeeesss, I copied the libraries and it works well. Thank you very very much, guys!