I have been meaning to chip in but so far hadn't got to it so hear goes.

In response to this particular issue I currently use numpy (1.2.1) built with msvc VS 2008 by simply commenting out these definitions in the numpy\core\src\umathmodule.c.src

That works just fine and allows me to use the built in lapack light that comes with numpy on 64-bit windows no problem.

I have spent many hours working on compiling a different lapack/blas implementation for windows with numpy so far with no joy, so would be very pleased if we can finally figure this out.

I have previously posted this link on the list:

http://icl.cs.utk.edu/lapack-for-windows/index.html

Using this package the intel visual fortran compiler and msvc C compiler I have managed to get most of numpy to compile against lapack/blas, but the process still trips up at linking with the folowwing message:

warning: build_ext: extension 'numpy.linalg.lapack_lite' has Fortran libraries but no Fortran linker found, using default linker

It complains about missing external symbols.

   Creating library build\temp.win-amd64-2.6\Release\numpy\linalg\lapack_lite.li
b and object build\temp.win-amd64-2.6\Release\numpy\linalg\lapack_lite.exp
lapack_litemodule.obj : error LNK2019: unresolved external symbol dgeev_ referen
ced in function lapack_lite_dgeev
lapack_litemodule.obj : error LNK2019: unresolved external symbol dsyevd_ refere
nced in function lapack_lite_dsyevd
lapack_litemodule.obj : error LNK2019: unresolved external symbol zheevd_ refere
nced in function lapack_lite_zheevd
lapack_litemodule.obj : error LNK2019: unresolved external symbol dgelsd_ refere
nced in function lapack_lite_dgelsd
lapack_litemodule.obj : error LNK2019: unresolved external symbol dgesv_ referen
ced in function lapack_lite_dgesv
lapack_litemodule.obj : error LNK2019: unresolved external symbol dgesdd_ refere
nced in function lapack_lite_dgesdd
lapack_litemodule.obj : error LNK2019: unresolved external symbol dgetrf_ refere
nced in function lapack_lite_dgetrf
lapack_litemodule.obj : error LNK2019: unresolved external symbol dpotrf_ refere
nced in function lapack_lite_dpotrf
lapack_litemodule.obj : error LNK2019: unresolved external symbol dgeqrf_ refere
nced in function lapack_lite_dgeqrf
lapack_litemodule.obj : error LNK2019: unresolved external symbol dorgqr_ refere
nced in function lapack_lite_dorgqr
lapack_litemodule.obj : error LNK2019: unresolved external symbol zgeev_ referen
ced in function lapack_lite_zgeev
lapack_litemodule.obj : error LNK2019: unresolved external symbol zgelsd_ refere
nced in function lapack_lite_zgelsd
lapack_litemodule.obj : error LNK2019: unresolved external symbol zgesv_ referen
ced in function lapack_lite_zgesv
lapack_litemodule.obj : error LNK2019: unresolved external symbol zgesdd_ refere
nced in function lapack_lite_zgesdd
lapack_litemodule.obj : error LNK2019: unresolved external symbol zgetrf_ refere
nced in function lapack_lite_zgetrf
lapack_litemodule.obj : error LNK2019: unresolved external symbol zpotrf_ refere
nced in function lapack_lite_zpotrf
lapack_litemodule.obj : error LNK2019: unresolved external symbol zgeqrf_ refere
nced in function lapack_lite_zgeqrf
lapack_litemodule.obj : error LNK2019: unresolved external symbol zungqr_ refere
nced in function lapack_lite_zungqr
build\lib.win-amd64-2.6\numpy\linalg\lapack_lite.pyd : fatal error LNK1120: 18 u
nresolved externals
error: Command "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\
link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:"C:\Program Files (x86)\Universit
y Of Tennessee\LAPACK 3.1.1\lib\x64" /LIBPATH:C:\Python26\libs /LIBPATH:C:\Pytho
n26\PCbuild\amd64 LAPACK.lib BLAS.lib /EXPORT:initlapack_lite build\temp.win-amd
64-2.6\Release\numpy\linalg\lapack_litemodule.obj /OUT:build\lib.win-amd64-2.6\n
umpy\linalg\lapack_lite.pyd /IMPLIB:build\temp.win-amd64-2.6\Release\numpy\linal
g\lapack_lite.lib /MANIFESTFILE:build\temp.win-amd64-2.6\Release\numpy\linalg\la
pack_lite.pyd.manifest" failed with exit status 1120

I suspect persuading setup.py to use the appropriate linker will sort this out, but I haven't had time to address what - I hope - could be the final hurdle.

Hanni


2009/1/29 Michael Colonno <mcolonno@gmail.com>
   OK, some progress here. I have two questions: 1) Let's forget about the Intel compiler(s) for the moment and focus on a standard Windows build. Python 2.6 comes with two classes in distutils: msvccompiler.py and msvc9compiler.py. In reading through these, it appears msvc9compiler.py is ideally suited for what I'm trying to do (use VS 2008 tools). Is it possible to select this via command line flags with config --compiler=xxx? Choosing "msvc" seems to go for msvccompiler.py (I'm just tyring to trace the magic as things build). 2) when using the standard msvc setup, things do seem to work re: setting up the build environemnt (see below). Now, the VS compiler kicks out a syntax error (output copied below). Any thoughts? This looks like a peculiarity of the VS compiler but I'm not sure. (I tend to prefer the Intel C compiler because it is more "Linux-like" and seems to be happier with cross-platform code.)

   Thanks,
   ~Mike C.

-----------------------

[copying.... output edited for bevity]

running build_ext
No module named msvccompiler in numpy.distutils; trying from distutils
customize MSVCCompiler
customize MSVCCompiler using build_ext
building 'numpy.core.multiarray' extension
compiling C sources
creating build\temp.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release
creating build\temp.win-amd64-2.6\Release\numpy
creating build\temp.win-amd64-2.6\Release\numpy\core
creating build\temp.win-amd64-2.6\Release\numpy\core\src
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c /nolog
o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src -Inumpy\cor
e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -Inumpy\core\src -I
numpy\core\include -IC:\Python26\include -IC:\Python26\PC /Tcnumpy\core\src\mult
iarraymodule.c /Fobuild\temp.win-amd64-2.6\Release\numpy\core\src\multiarraymodu
le.obj
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe /DLL /n
ologo /INCREMENTAL:NO /LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild\amd
64 /EXPORT:initmultiarray build\temp.win-amd64-2.6\Release\numpy\core\src\multia
rraymodule.obj /OUT:build\lib.win-amd64-2.6\numpy\core\multiarray.pyd /IMPLIB:bu
ild\temp.win-amd64-2.6\Release\numpy\core\src\multiarray.lib /MANIFESTFILE:build
\temp.win-amd64-2.6\Release\numpy\core\src\multiarray.pyd.manifest
mt.exe -nologo -manifest build\temp.win-amd64-2.6\Release\numpy\core\src\multiar
ray.pyd.manifest -outputresource:build\lib.win-amd64-2.6\numpy\core\multiarray.p
yd;2
building 'numpy.core.umath' extension
compiling C sources
creating build\temp.win-amd64-2.6\Release\build
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c /nolog
o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src -Inumpy\cor
e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -Inumpy\core\src -I
numpy\core\include -IC:\Python26\include -IC:\Python26\PC /Tcbuild\src.win-amd64
-2.6\numpy\core\src\umathmodule.c /Fobuild\temp.win-amd64-2.6\Release\build\src.
win-amd64-2.6\numpy\core\src\umathmodule.obj
umathmodule.c
numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
numpy\core\src\ufuncobject.c(1704) : warning C4244: '=' : conversion from 'npy_i
ntp' to 'int', possible loss of data
numpy\core\src\ufuncobject.c(2425) : warning C4244: '=' : conversion from 'npy_i
ntp' to 'int', possible loss of data
error: Command "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\
cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core
\src -Inumpy\core\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -In
umpy\core\src -Inumpy\core\include -IC:\Python26\include -IC:\Python26\PC /Tcbui
ld\src.win-amd64-2.6\numpy\core\src\umathmodule.c /Fobuild\temp.win-amd64-2.6\Re
lease\build\src.win-amd64-2.6\numpy\core\src\umathmodule.obj" failed with exit s
tatus 2

-----------------------


On Wed, Jan 28, 2009 at 4:36 PM, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Jan 29, 2009 at 1:18 AM, Michael Colonno <mcolonno@gmail.com> wrote:
>    I think this is doable; thankfully the Intel compilers on Windows and
> Linux are very similar in behavior.

The problem is that distutils does not abstract this kind of things:
you have a CCompiler class, and a subclass Unix C Compiler, and then
Intel Compiler. OTOH, the MS compiler is its own class which inherit
from CCompiler - all windows specifics are encoded in this class. So I
am afraid you will need to recreate all this class implementation for
Intel C Compiler, because contrary to the Linux case, nothing is
abstracted for windows.

> As an aside: how were the Windows 32-bit installers created?

With mingw compiler.

> Is
> it possible to recreate this process changing the target arch --> x64?

If you can build numpy with the Intel compiler, building the installer
should be a no-brainer.

cheers,

David
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion