[Numpy-discussion] Building on WinXP 64-bit, Intel Compilers

Fri Jan 30 07:32:48 EST 2009

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 at 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 at gmail.com>wrote:
>
>> On Thu, Jan 29, 2009 at 1:18 AM, Michael Colonno <mcolonno at 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 at scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090130/ae19bcd7/attachment.html>