Hi ~ I'm trying to build numpy (hopefully eventually scipy with the same setup) with the Intel compilers (and Intel MKL) on the WinXP 64-bit platform. Finding / linking to the Intel MKL seems to be successful (see below) but I have an issue with the settings defined somewhere in the various setup scripts (can't find where). Per the output below, the Intel compilers on Windows are looking for ".obj" object files rather than the Linux-style ".o" files. I'd also like to get rid of the /L and -L flags (no longer supported in Intel C++ v. 11.0 it seems) but this just throws a warning and does not seem to cause any problems. Can anyone point me to the python file(s) I need to edit to modify the .o object file setting to .obj? (The file "_configtest.obj" is created.) Once operational, I'll pass along all of my config info for anyone else building in this environment. Thanks! ~Mike C. Output from build:
python setup.py config --compiler=intel --fcompiler=intelem install
Running from numpy source directory. Forcing DISTUTILS_USE_SDK=1 F2PY Version 2_5972 blas_opt_info: blas_mkl_info: FOUND: libraries = ['mkl_em64t', 'mkl_dll'] library_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\ 061\\cpp\\m kl\\em64t\\lib'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\include'] FOUND: libraries = ['mkl_em64t', 'mkl_dll'] library_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\em64t\\lib'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\include'] lapack_opt_info: lapack_mkl_info: mkl_info: FOUND: libraries = ['mkl_em64t', 'mkl_dll'] library_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\em64t\\lib'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\include'] FOUND: libraries = ['mkl_lapack', 'mkl_em64t', 'mkl_dll'] library_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\em64t\\lib'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\include'] FOUND: libraries = ['mkl_lapack', 'mkl_em64t', 'mkl_dll'] library_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\em64t\\lib'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['C:\\Program Files (x86)\\Intel\\Compiler\\11.0\\061\\cpp\\m kl\\include'] running config running install running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler opti ons running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler opt ions running build_src building py_modules sources creating build creating build\src.win32-2.5 creating build\src.win32-2.5\numpy creating build\src.win32-2.5\numpy\distutils building extension "numpy.core.multiarray" sources creating build\src.win32-2.5\numpy\core Generating build\src.win32-2.5\numpy\core\include/numpy\config.h Could not locate executable icc Could not locate executable ecc Ignoring "MSVCCompiler instance has no attribute '_MSVCCompiler__root'" (I think it is msvccompiler.py bug) customize IntelEM64TFCompiler Found executable C:\Program Files (x86)\Intel\Compiler\11.0\061\fortran\Bin\inte l64\ifort.exe Found executable C:\Program Files (x86)\Intel\Compiler\11.0\061\fortran\Bin\inte l64\ifort.exe C compiler: icl compile options: '-IC:\Python25\include -Inumpy\core\src -Inumpy\core\include -I C:\Python25\include -IC:\Python25\PC -c' icl: _configtest.c Found executable C:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\Bin\intel64\ icl.exe icl _configtest.o -LC:\Python25\lib -LC:\ -LC:\Python25\libs -o _configtest Intel(R) C++ Intel(R) 64 Compiler Professional for applications running on Intel (R) 64, Version 11.0 Build 20080930 Package ID: w_cproc_p_11.0.061 Copyright (C) 1985-2008 Intel Corporation. All rights reserved. icl: command line warning #10161: unrecognized source type '_configtest.o'; obje ct file assumed icl: command line warning #10006: ignoring unknown option '/LC:\Python25\lib' icl: command line warning #10006: ignoring unknown option '/LC:\' icl: command line warning #10006: ignoring unknown option '/LC:\Python25\libs' ipo: warning #11009: file format not recognized for _configtest.o Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:_configtest.exe _configtest.o LINK : fatal error LNK1181: cannot open input file '_configtest.o' failure. removing: _configtest.c _configtest.o Traceback (most recent call last): File "setup.py", line 96, in <module> setup_package() File "setup.py", line 89, in setup_package configuration=configuration ) File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\core.py", line 184, in setup return old_setup(**new_attr) File "C:\Python25\lib\distutils\core.py", line 151, in setup dist.run_commands() File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "C:\Python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\command\install.py", line 49, in run r = old_install.run(self) File "C:\Python25\lib\distutils\command\install.py", line 506, in run self.run_command('build') File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\Python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\command\build.py", line 37, in run old_build.run(self) File "C:\Python25\lib\distutils\command\build.py", line 112, in run self.run_command(cmd_name) File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\Python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\command\build_src.py", line 130, in run self.build_sources() File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\command\build_src.py", line 147, in build_sources self.build_extension_sources(ext) File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\command\build_src.py", line 250, in build_extension_sources sources = self.generate_sources(sources, ext) File "C:\Documents and Settings\mike\Desktop\Software\Python\numpy-1.2.1\numpy \distutils\command\build_src.py", line 307, in generate_sources source = func(extension, build_dir) File "numpy\core\setup.py", line 87, in generate_config_h raise SystemError,"Failed to test configuration. "\ SystemError: Failed to test configuration. See previous error messages for more information.
Michael Colonno wrote:
Hi ~
I'm trying to build numpy (hopefully eventually scipy with the same setup) with the Intel compilers (and Intel MKL) on the WinXP 64-bit platform. Finding / linking to the Intel MKL seems to be successful (see below)
Unfortunately, at this stage, it does not say much about linking: distutils look for files, and do not do any sanity check beyond that.
but I have an issue with the settings defined somewhere in the various setup scripts (can't find where). Per the output below, the Intel compilers on Windows are looking for ".obj" object files rather than the Linux-style ".o" files.
I think the problem is simply that intel support in numpy for the C compiler is limited to unix. At least, a quick look at the sources did not give much informations about windows support: --compiler=intel does call for the unix version (icc, and this is called first as you can see in your log). I am actually puzzled: where is the icl.exe coming from ? grep icl gives nothing in numpy, and nothing in python - did you by any chance build python itself with the Intel compiler ? cheers, David
Thanks for your response. I manually edited one of the python files (ccompiler.py I think) to change icc.exe to icl.exe. (This is a trick I used to use to get F2PY to compile on Windows platforms.) Since icl is a drop-in replacement for the visual studio compiler / linker, I'd like to edit the python files configuring this (msvc) but I could not find anything(?) If you could point me towards the config files(s) for the visual studio compiler (I'm assuming are configured for the Windows file extensions already) I could likely make some headway. Thanks, ~Mike C. On Tue, Jan 27, 2009 at 6:39 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Michael Colonno wrote:
Hi ~
I'm trying to build numpy (hopefully eventually scipy with the same setup) with the Intel compilers (and Intel MKL) on the WinXP 64-bit platform. Finding / linking to the Intel MKL seems to be successful (see below)
Unfortunately, at this stage, it does not say much about linking: distutils look for files, and do not do any sanity check beyond that.
but I have an issue with the settings defined somewhere in the various setup scripts (can't find where). Per the output below, the Intel compilers on Windows are looking for ".obj" object files rather than the Linux-style ".o" files.
I think the problem is simply that intel support in numpy for the C compiler is limited to unix. At least, a quick look at the sources did not give much informations about windows support: --compiler=intel does call for the unix version (icc, and this is called first as you can see in your log). I am actually puzzled: where is the icl.exe coming from ? grep icl gives nothing in numpy, and nothing in python - did you by any chance build python itself with the Intel compiler ?
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Michael Colonno wrote:
Thanks for your response. I manually edited one of the python files (ccompiler.py I think) to change icc.exe to icl.exe. (This is a trick I used to use to get F2PY to compile on Windows platforms.) Since icl is a drop-in replacement for the visual studio compiler / linker, I'd like to edit the python files configuring this (msvc) but I could not find anything(?) If you could point me towards the config files(s) for the visual studio compiler (I'm assuming are configured for the Windows file extensions already) I could likely make some headway.`
Unfortunately, the code for our building process is difficult to grasp - there is a lof of magic. Everything is in numpy/distutils. Basically, you need to create a new compiler, a bit like intelccompiler.py, but for Windows. I unfortunately can't help you more ATM, since I don't know the intel compiler on Windows. cheers, David
On Wed, Jan 28, 2009 at 1:06 AM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Michael Colonno wrote:
Thanks for your response. I manually edited one of the python files (ccompiler.py I think) to change icc.exe to icl.exe. (This is a trick I used to use to get F2PY to compile on Windows platforms.) Since icl is a drop-in replacement for the visual studio compiler / linker, I'd like to edit the python files configuring this (msvc) but I could not find anything(?) If you could point me towards the config files(s) for the visual studio compiler (I'm assuming are configured for the Windows file extensions already) I could likely make some headway.`
Unfortunately, the code for our building process is difficult to grasp - there is a lof of magic. Everything is in numpy/distutils. Basically, you need to create a new compiler, a bit like intelccompiler.py, but for Windows. I unfortunately can't help you more ATM, since I don't know the intel compiler on Windows.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
I think this is doable; thankfully the Intel compilers on Windows and Linux are very similar in behavior. The exact same build scripts *should*work fine provided the file extensions (.o --> .obj) and flags (-L, etc.) are modified. In terms of syntax this should be an easy thing to do (it was with the free-standing F2PY) , but I will need some help navigating through the magic you refer to. I will put some effort into this and write back if I hit a roadblock. As an aside: how were the Windows 32-bit installers created? Is it possible to recreate this process changing the target arch --> x64? Thanks again, ~Mike C. On Wed, Jan 28, 2009 at 1:06 AM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Michael Colonno wrote:
Thanks for your response. I manually edited one of the python files (ccompiler.py I think) to change icc.exe to icl.exe. (This is a trick I used to use to get F2PY to compile on Windows platforms.) Since icl is a drop-in replacement for the visual studio compiler / linker, I'd like to edit the python files configuring this (msvc) but I could not find anything(?) If you could point me towards the config files(s) for the visual studio compiler (I'm assuming are configured for the Windows file extensions already) I could likely make some headway.`
Unfortunately, the code for our building process is difficult to grasp - there is a lof of magic. Everything is in numpy/distutils. Basically, you need to create a new compiler, a bit like intelccompiler.py, but for Windows. I unfortunately can't help you more ATM, since I don't know the intel compiler on Windows.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
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
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
Michael Colonno wrote:
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?
No - python-distutils normally builds extensions with the same compiler as the one used to build python itself. Which means VS 2008 for python 2.6, VS 2003 .Net for 2.5 (except for 64 bits which uses a variant of VS 2005). You *cannot* build an extension with VS 2008 for a python built with VS 2003, for various fundamental reasons.
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.)
Most numpy/scipy developers use gcc compilers on most platforms, so sometimes some things which do not pass with another compiler slip in. It is possible that this is the case here - but I could build numpy with VS 2008 on windows x64 a few weeks ago, so it should only be a relatively small regression. I will look at it, David
OK, I think I have a much better understanding of how this all gets assembled now. I've got the build environment using both Intel compilers (C++ and Fortran) and linked to the Intel MKL. Using the Intel C compiler (icl.exe, more "gcc-like") as a replacement cl.exe (it supports the same options, flags, and such thankfully), the build proceeds further, but eventually kicks out with the syntax / parsing error copied below. Let me know what you think. Thanks! ~Mike C. ---------------------------------- [edited] 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)\Intel\Compiler\11.0\061\cpp\Bin\intel64\icl.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: expected an identifier static float frexpf(float x, int * i) ^ numpy\core\src\umathmodule.c.src(64): error: expected a ")" static float frexpf(float x, int * i) ^ numpy\core\src\umathmodule.c.src(65): error: expected a ";" { ^ numpy\core\src\umathmodule.c.src(84): warning #12: parsing restarts here after p revious syntax error double log1p(double); ^ numpy\core\include\numpy/ufuncobject.h(358): warning #177: function "generate_ov erflow_error" was declared but never referenced static void generate_overflow_error(void) { ^ compilation aborted for build\src.win-amd64-2.6\numpy\core\src\umathmodule.c (co de 2) error: Command "C:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\Bin\intel64\i 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 Thu, Jan 29, 2009 at 7:59 AM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Michael Colonno wrote:
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?
No - python-distutils normally builds extensions with the same compiler as the one used to build python itself. Which means VS 2008 for python 2.6, VS 2003 .Net for 2.5 (except for 64 bits which uses a variant of VS 2005). You *cannot* build an extension with VS 2008 for a python built with VS 2003, for various fundamental reasons.
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.)
Most numpy/scipy developers use gcc compilers on most platforms, so sometimes some things which do not pass with another compiler slip in. It is possible that this is the case here - but I could build numpy with VS 2008 on windows x64 a few weeks ago, so it should only be a relatively small regression. I will look at it,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
numpy\core\src\umathmodule.c.src(64): error: expected an identifier static float frexpf(float x, int * i) ^
numpy\core\src\umathmodule.c.src(64): error: expected a ")" static float frexpf(float x, int * i) ^
numpy\core\src\umathmodule.c.src(65): error: expected a ";" { ^
Perhaps a macro that is replaced? Visual Studio defines min, max as macros. Maybe it is the same for frexpf? Could you check in the preprocessed C++ file ? /E to generate it Intel Compiler, I think. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
Not sure if it's a VS thing since I get different compile errors with either the MS or Intel C compiler under the same environment (Visual Studio for x64 console). Let me start with a more basic question: I'm using the package available on SourceForge (1.2.1, 2008-10-29 14:36). If it can be confirmed this package builds happily via VS 2008 x64 console, can I get a look at the build log and/or configuration? I should be able to duplicate this with identical tools (I hope). If it makes a difference I will try to grab the latest & greatest source instead. Thanks, ~Mike C. On Thu, Jan 29, 2009 at 8:50 AM, Matthieu Brucher < matthieu.brucher@gmail.com> wrote:
numpy\core\src\umathmodule.c.src(64): error: expected an identifier static float frexpf(float x, int * i) ^
numpy\core\src\umathmodule.c.src(64): error: expected a ")" static float frexpf(float x, int * i) ^
numpy\core\src\umathmodule.c.src(65): error: expected a ";" { ^
Perhaps a macro that is replaced? Visual Studio defines min, max as macros. Maybe it is the same for frexpf? Could you check in the preprocessed C++ file ? /E to generate it Intel Compiler, I think.
Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jan 30, 2009 at 2:43 AM, Michael Colonno <mcolonno@gmail.com> wrote:
Not sure if it's a VS thing since I get different compile errors with either the MS or Intel C compiler under the same environment (Visual Studio for x64 console). Let me start with a more basic question: I'm using the package available on SourceForge (1.2.1, 2008-10-29 14:36). If it can be confirmed this package builds happily via VS 2008 x64 console, can I get a look at the build log and/or configuration? I should be able to duplicate this with identical tools (I hope). If it makes a difference I will try to grab the latest & greatest source instead.
Oh, you should forget about 1.2.1 for windows x64. A lot of fixes have been applied since then, and in any case, I won't try to fix 1.2.1 build problems. You should definitely use svn if you care about windows x64 - I hope 1.3.0 will be fully supported on that platform. David
OK, I'm on the cusp of success now. I updated to the most recent code and get to a sequence of errors surround math functions. This must be due to linking the MKL libs. I tried various combinations (including those recommended by the MKL docs) but could not get around the errors. Looks like a missing header file(?) In any event, I hope this can be fixed by getting the right into in site.cfg. Currently I have: [mkl] include_dirs = C:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\mkl\include library_dirs = C:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\mkl\em64t\lib mkl_libs = mkl_em64t, mkl_dll, mkl_core # various combinations of other tried... lapack_libs = mkl_lapack Below is the relevant portion of the output. During config the libraries check in as "FOUND" so I'm pretty sure the paths above are good. Thanks, ~Mike C. --------------------------- [edited] numpy\core\src\umath_funcs.inc.src(557): warning #266: function "sinhl" declared implicitly shr = sinhl(xr); ^ numpy\core\src\umath_funcs.inc.src(558): warning #266: function "coshl" declared implicitly chr = coshl(xr); ^ numpy\core\src\umath_loops.inc.src(913): warning #266: function "floorl" declare d implicitly *((longdouble *)op1) = floorl(in1/in2); ^ numpy\core\src\umath_loops.inc.src(923): warning #266: function "fmodl" declared implicitly const longdouble res = fmodl(in1,in2); ^ numpy\core\src\umath_loops.inc.src(1003): warning #266: function "modfl" declare d implicitly *((longdouble *)op1) = modfl(in1, (longdouble *)op2); ^ numpy\core\src\umath_loops.inc.src(1207): warning #266: function "fabsf" declare d implicitly if (fabsf(in1i) <= fabsf(in1r)) { ^ numpy\core\src\umath_loops.inc.src(1110): warning #266: function "floorl" declar ed implicitly ((longdouble *)op1)[0] = floorl((in1r*in2r + in1i*in2i)/d); ^ numpy\core\src\umath_loops.inc.src(1207): warning #266: function "fabsl" declare d implicitly if (fabsl(in1i) <= fabsl(in1r)) { ^ numpy\core\src\umath_loops.inc.src(1246): warning #266: function "sqrtl" declare d implicitly *((longdouble *)op1) = sqrtl(in1r*in1r + in1i*in1i); ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(244): error : identifier "acosl" is undefined arccos_data[2] = (void *) acosl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(253): error : identifier "acoshf" is undefined arccosh_data[0] = (void *) acoshf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(257): error : identifier "acoshl" is undefined arccosh_data[2] = (void *) acoshl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(270): error : identifier "asinl" is undefined arcsin_data[2] = (void *) asinl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(279): error : identifier "asinhf" is undefined arcsinh_data[0] = (void *) asinhf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(283): error : identifier "asinhl" is undefined arcsinh_data[2] = (void *) asinhl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(296): error : identifier "atanl" is undefined arctan_data[2] = (void *) atanl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(309): error : identifier "atan2l" is undefined arctan2_data[2] = (void *) atan2l; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(312): error : identifier "atanhf" is undefined arctanh_data[0] = (void *) atanhf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(316): error : identifier "atanhl" is undefined arctanh_data[2] = (void *) atanhl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(335): error : identifier "ceill" is undefined ceil_data[2] = (void *) ceill; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(343): error : identifier "cosl" is undefined cos_data[2] = (void *) cosl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(356): error : identifier "coshl" is undefined cosh_data[2] = (void *) coshl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(385): error : identifier "expl" is undefined exp_data[2] = (void *) expl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(394): error : identifier "exp2f" is undefined exp2_data[0] = (void *) exp2f; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(396): error : identifier "exp2" is undefined exp2_data[1] = (void *) exp2; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(398): error : identifier "exp2l" is undefined exp2_data[2] = (void *) exp2l; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(401): error : identifier "expm1f" is undefined expm1_data[0] = (void *) expm1f; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(405): error : identifier "expm1l" is undefined expm1_data[2] = (void *) expm1l; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(414): error : identifier "fabsf" is undefined fabs_data[0] = (void *) fabsf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(418): error : identifier "fabsl" is undefined fabs_data[2] = (void *) fabsl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(425): error : identifier "floorl" is undefined floor_data[2] = (void *) floorl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(438): error : identifier "fmodl" is undefined fmod_data[12] = (void *) fmodl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(441): error : identifier "hypotf" is undefined hypot_data[0] = (void *) hypotf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(445): error : identifier "hypotl" is undefined hypot_data[2] = (void *) hypotl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(456): error : identifier "logl" is undefined log_data[2] = (void *) logl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(469): error : identifier "log10l" is undefined log10_data[2] = (void *) log10l; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(478): error : identifier "log1pf" is undefined log1p_data[0] = (void *) log1pf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(482): error : identifier "log1pl" is undefined log1p_data[2] = (void *) log1pl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(491): error : identifier "log2f" is undefined log2_data[0] = (void *) log2f; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(493): error : identifier "log2" is undefined log2_data[1] = (void *) log2; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(495): error : identifier "log2l" is undefined log2_data[2] = (void *) log2l; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(534): error : identifier "powl" is undefined power_data[12] = (void *) powl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(564): error : identifier "rintf" is undefined rint_data[0] = (void *) rintf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(566): error : identifier "rint" is undefined rint_data[1] = (void *) rint; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(568): error : identifier "rintl" is undefined rint_data[2] = (void *) rintl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(581): error : identifier "sinl" is undefined sin_data[2] = (void *) sinl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(594): error : identifier "sinhl" is undefined sinh_data[2] = (void *) sinhl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(607): error : identifier "sqrtl" is undefined sqrt_data[2] = (void *) sqrtl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(624): error : identifier "tanl" is undefined tan_data[2] = (void *) tanl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(637): error : identifier "tanhl" is undefined tanh_data[2] = (void *) tanhl; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(648): error : identifier "truncf" is undefined trunc_data[0] = (void *) truncf; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(650): error : identifier "trunc" is undefined trunc_data[1] = (void *) trunc; ^ build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(652): error : identifier "truncl" is undefined trunc_data[2] = (void *) truncl; ^ numpy\core\include\numpy/ufuncobject.h(372): warning #177: function "generate_ov erflow_error" was declared but never referenced static void generate_overflow_error(void) { ^ numpy\core\src\umath_funcs.inc.src(70): warning #177: function "exp2_1mf" was de clared but never referenced exp2_1mf(float x) ^ numpy\core\src\umath_funcs.inc.src(70): warning #177: function "exp2_1m" was dec lared but never referenced exp2_1m(double x) ^ numpy\core\src\umath_funcs.inc.src(70): warning #177: function "exp2_1ml" was de clared but never referenced exp2_1ml(longdouble x) ^ compilation aborted for build\src.win-amd64-2.6\numpy\core\src\umathmodule.c (co de 2) error: Command "C:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\Bin\intel64\i 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
This is the first failure in the build log: _configtest.c _configtest.c(1): catastrophic error: could not open source file "inttypes.h" #include <inttypes.h> ^ compilation aborted for _configtest.c (code 4) failure. I don't have this file anywhere on my system; it appears to be a gcc header file. Any suggestions? Thanks, ~Mike C.
On Fri, Jan 30, 2009 at 9:41 AM, Michael Colonno <mcolonno@gmail.com> wrote:
This is the first failure in the build log:
_configtest.c _configtest.c(1): catastrophic error: could not open source file "inttypes.h" #include <inttypes.h> ^
compilation aborted for _configtest.c (code 4) failure.
That's strange, because configtest.c means it is a configuration test, and failure just means the tested feature is not available on the platform - it should certainly not stop the build process. Is this with Intel compiler ? I think I remembered having seen some bug either in python or Intel Compiler in the error return code when launching intel compiler in a subprocess. I just checked the last svn version on windows 64: it builds OK with compiler version 15 (either VS 2008 for 64 bits, which I don't have access to, or with the Platform SDK 6.1, which is free). David
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
participants (5)
-
David Cournapeau -
David Cournapeau -
Hanni Ali -
Matthieu Brucher -
Michael Colonno