David Cournapeau wrote:
Michael Abshoff wrote:
Well, I think that having a 64 bit native build of numpy/scipy using an efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL) can't be a bad thing :)
Yes, of course. But it is useful to be able to use a 32 bits toolchain to produce 64 bits software.
Sure, but there isn't even a 32 bit gcc out there that can produce 64 bit PE binaries (aside from the MinGW fork that AFAIK does not work particularly well and allegedly has issues with the cleanliness of some of the code which is allegedly the reason that the official MinGW people will not touch the code base) . It has been rumored for a while that there is a new version of SFU by Microsoft in the works based on gcc 4.2.x that will be able create 64 bit PE binaries, but I have not actually talked to anybody who has access, so it could be just a rumor.
It might be possible to build python [2.5|2.6|3.0] with MinGW itself to avoid the runtime issue. At least Python 2.4 had problems when building it with MinGW and I never investigated if 2.5.x had fixed those issues.
Not being ABI compatible with Python from python.org is not an option, and building it with mingw would make it ABI incompatible for sure. I certainly wished they used an open source compiler to build the official python binary, but that's not the case.
Ok, that is a concern I usually do not have since I tend to build my own Python :).
I am pretty sure that building Python with MinGW will break ABI compatibility with Python 2.6. As has been discussed on this list more than once not even Python 2.5 build with MSVC 2003 is really compatible with C++ extensions build with MinGW.
Numpy-discussion mailing list Numpyemail@example.com http://projects.scipy.org/mailman/listinfo/numpy-discussion