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 <mcolo...@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 <courn...@gmail.com>wrote: > >> On Thu, Jan 29, 2009 at 1:18 AM, Michael Colonno <mcolo...@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 > >
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion