On Fri, 30 Jul 2004 13:14:23 -0700, Chris Barker wrote

Hi all,

just to keep this thread moving--- I'm trying to get Numeric working with a native lapack on Windows also. I know little enough about this kindo f thing on LInux, and I'm really out of my depth on Windows.

This is what I have done so far:

After much struggling, I got Numeric to compile using setup.py, and MS Visual Studio .NET 2003 (or whatever the heck it's called!)

It all seems to work fine with the include lapack-lite.

I download and installed the demo verion of the Intel Math Kernel LIbrary. I set up various paths so that setup.py find the libs, but now I get linking errors:

unresolved external symbol _dgeev_ referenced in function _lapack_lite_dgetrf

And a whole bunch of others, all corresponding to the various LaPack calls.

I am linking against Intel's mkl_c.lib, which is supposed tohave everything in it. Indeed, if I look in teh lib file, I find, for example:

...evx._DGEEV._dgeev._DGB ...

so it lkooks like they are there, but perhaps referred to with only one underscore, at the beginning, rather than one at each end.

Now I'm stuck.

I suppose I could use ATLAS, but it looked like it was going to take some effort to compile that under with MSVC.

Has anyone gotten a native BLAS working on Windows? if so, how?

In lapack_lite.c, you''ll see: #if defined(NO_APPEND_FORTRAN) lapack_lite_status__ = dgeev(&jobvl,&jobvr,&n,DDATA(a),&lda,DDATA(wr),DDATA(wi),DDATA(vl),&ldvl,DDATA(vr),&ldvr,DDATA(work),&lwork,&info); #else lapack_lite_status__ = dgeev_(&jobvl,&jobvr,&n,DDATA(a),&lda,DDATA(wr),DDATA(wi),DDATA(vl),&ldvl,DDATA(vr),&ldvr,DDATA(work),&lwork,&info); #endif So, try to define NO_APPEND_FORTRAN. If that does not work, you can try to prepend an underscore. You can also try to rip the ATLAS and supposedly ATLAS enhanced lapack libraries out of scipy and build against those (not as good as http://www.scipy.org/documentation/buildatlas4scipywin32.txt, but better than nothing). Gerard