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.

   ~Mike C.



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.
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,

Numpy-discussion mailing list