
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