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

Michael Colonno mcolonno@gmail....
Thu Jan 29 10:44:10 CST 2009


   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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20090129/ce2f3e57/attachment.html 


More information about the Numpy-discussion mailing list