Hi folks ~
Any thoughts on the below? I n searching the web I found some other
references to ImportError: DLL load failed: Invalid access to memory
location but none specific to Numpy. As an aside: will there be a Windows x64
binary distributed with the next release of
On Tue, Feb 3, 2009 at 12:28 AM, Mike Colonno mike.colo...@spacex.com wrote:
Hi folks ~
Any thoughts on the below?
It is hard to say, but I suspect a problem in your BLAS/LAPACK because
it fails on importing lapack_lite. Your error message is so generic
that it does
Hi David,
I used free trials of the Intel and PGI compilers to try to compile an
external BLAS/LAPACK in conjunction with VS 2008. I also had no problems
getting the C code to compile, but couldn't get linking to work succesfully
with fortran stuff. I would not be surprised if we could get a
On Tue, Feb 3, 2009 at 2:23 AM, Hanni Ali hanni@gmail.com wrote:
Hi David,
I used free trials of the Intel and PGI compilers to try to compile an
external BLAS/LAPACK in conjunction with VS 2008. I also had no problems
getting the C code to compile, but couldn't get linking to work
Maybe I declared success too soon... The build / install of numpy seems to
work (using MS C++ / Intel Fortran), but upon trying to import numpy I get:
from numpy import *
Traceback (most recent call last):
File C:\string, line 1, in module
File
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
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
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
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,
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:
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
On Fri, Jan 30, 2009 at 2:43 AM, Michael Colonno mcolo...@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
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
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
On Fri, Jan 30, 2009 at 9:41 AM, Michael Colonno mcolo...@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
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 /
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
On Thu, Jan 29, 2009 at 1:18 AM, Michael Colonno mcolo...@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
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
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
20 matches
Mail list logo
