
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