[Numpy-discussion] Building Numeric with a native blas -- On Windows

gerard.vermeulen at grenoble.cnrs.fr gerard.vermeulen at grenoble.cnrs.fr
Fri Jul 30 15:04:10 CDT 2004

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__ =
lapack_lite_status__ =

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
but better than nothing).


More information about the Numpy-discussion mailing list