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 < da...@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-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion