search

thouis / numpy-trac-migration

numpy Trac to github issues migration
2 stars 3 forks source link

Can't Import numpy in windows xp 64, python 2.6.2 64 bit (migrated from Trac #1092) #2645

Open thouis opened 12 years ago

thouis commented 12 years ago

Original ticket http://projects.scipy.org/numpy/ticket/1092 Reported 2009-04-23 by trac user SevenThunders, assigned to atmention:rgommers.

The amd64 binary install of numpy fails using the binary install of the amd64 version of python 2.6.2. Installation occurs without error but an attempt to import numpy crashes python in the cmd.exe window and returns with no effect in IDLE. By no effect I mean numpy and it's methods are not visible.

I also compiled numpy using the latest 64 bit SDK from Microsoft (v15), and this reproduced the same errors. I don't know if this is the same problem in ticket 1084, but the behavior is a little different.

thouis commented 12 years ago

Comment in Trac by atmention:cournape, 2009-06-01

thouis commented 12 years ago

Comment in Trac by trac user cpbotha, 2009-06-04

I've just run into this exact behaviour with the numpy 1.3.0 amd64 MSI installer on an otherwise completely clean installation of Python 2.6.2 amd64 on a Windows XP 64 SP2 machine with Visual Studio 2008 installed.

The Python process terminates, without a hint of an error message, to the command prompt when one attempts "import numpy".

thouis commented 12 years ago

Comment in Trac by atmention:cournape, 2009-06-09

See #1112 - I think it is linked to incompatible C runtimes between numpy and python, but I am not sure. Debugging it is quite hard, as no stack trace is available, and I don't have access to something like valgrind for windows.

See also this:

http://stackoverflow.com/questions/961337/detecting-multiple-linked-c-runtime-on-windows

thouis commented 12 years ago

Comment in Trac by trac user cpbotha, 2009-06-09

What did you build the "official" windows x64 numpy binaries with? gcc toolchain or visual studio 2008 (like the Python 2.6.2 binaries themselves)? Does it not make sense to build them with the same toolchain as the official Python 2.6 binaries, or is this not practical? The documentation states that both are possible, but I did not understand all the caveats.

In the latter case, it would make sense to mention this in the readme somewhere, even although this support is experimental. Then people would know what (not) to expect. :)

thouis commented 12 years ago

Comment in Trac by atmention:cournape, 2009-06-09

It is built with mingw. Numpy built with VS 2008 works ok, but I have not found a way to use gfortran + VS 2008, and I am not so interested in building numpy without scipy. That's the rationale for using mingw (also, mingw can be used under wine, and can be used for several python versions, whereas you often have to use a different version of VS for every python version).

The experimental side is documnented, and you even get a message at import times, but in this case, it crashes before the import :)

thouis commented 12 years ago

Comment in Trac by trac user cpbotha, 2009-06-09

I read your stackoverflow post, but couldn't comment there due to lack of reputation. :P

In any case, I've been linking Python 2.5 Win32 (built with VS 2003) with both VTK and ITK DLLs, both built by myself, in several versions, always with VS 2005 (!!), with not a sniff of a problem. I've also been distributing binaries of the application in question (google "DeVIDE"), and pyinstaller simply picked out both the VS 2003 and VS 2005 runtimes as dependencies. These were shipped together with my application.

VTK and ITK are really large libraries. The chances of this working so stably for so many years over so many different builds by coincidence are very small.

This was of course Win32 and not Win64. Perhaps Win64 does something radically different in this regard. Also possible that whereas e.g. VS 2003 and VS 2005 work together, VS 2008 and mingw don't.

Oh well...

With regard to the documentation: I meant that a notice at download that the binaries were built with ming would be nice, then a non-working import with the official Python 2.6.2 binaries would not be so surprising at least. :)

BTW, if there's any other information that I could extract to help demystify this, lemme know. As it stands, I'm going to try to build my own binaries with VS 2008 on Win64 when I have some time (this would be without scipy). I have an ugly automated build system (google "DeVIDE johannes") that builds everything including numpy, on Linux 32 and 64, and mostly everything on Windows 32 and lately Windows 64, except that I got lazy with numpy and matplotlib due to the various extra dependencies that have to be installed on the build system.

thouis commented 12 years ago

Comment in Trac by atmention:mwiebe, 2011-03-24

Ralf, do you want to close this? I imagine any 64 bit win32 build issues are being caught in the 1.6 beta testing.

thouis commented 12 years ago

Comment in Trac by atmention:rgommers, 2011-03-25

This is about the experimental 64-bit binary for numpy 1.3.0 produced with MinGW by David. We don't release those anymore so for me it's not relevant. I don't know if David wants to come back to this topic and give it another try though - it's up to him to close this.

thouis commented 12 years ago

Comment in Trac by atmention:rgommers, 2011-03-30