I get the following errors in umathmodule.c.src:

D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.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 -Id:\python26\include -Id:\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

Could you compress win-amd64-2.6\numpy\core\src\umathmodule.c -- it should be in the build directory -- and attach it if possible, or at least that

On Tue, Oct 7, 2008 at 11:42 AM, Paul Lucek wrote: part that seems to be a problem? Mind that the list has a rather small size limit.

umathmodule.c

numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'

numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'

numpy\core\src\ufuncobject.c(1701) : warning C4244: '=' : conversion from 'npy_i

ntp' to 'int', possible loss of data

numpy\core\src\ufuncobject.c(2422) : warning C4244: '=' : conversion from 'npy_i

ntp' to 'int', possible loss of data

The warnings are known.

Chuck

Peter wrote:

How about python 2.5 and numpy 1.2 instead? Python 2.6 makes some important changes to python 2.5 (in preparation for Python 3.0), so you may find several other packages will take a couple of months to work 100% with python 2.6 - so check this out if you do plan to use more than just numpy. There are sometimes drawbacks to using brand new releases ;)

If I understand Ravi right, one problem with 2.5 is that it relies on an old toolset (VS 2003, not available anymore). OTOH, 2.6 depends on the most recent toolset, which is also available for free in a limited version (VS 2008 express). If you think about supporting things for a couple of years, relying on VS 2008 sounds safer than 2003. cheers, David

Ravi wrote:

On Wednesday 08 October 2008 03:39:32 David Cournapeau wrote:

...

Note that 1.2.0 does not officially support python 2.6, specially on windows. Because python 2.6 uses a new toolchain (VS 2008 by default instead of 2003), it requires some non trivial changes.

How extensive are these non-trivial changes? I could help test any changes.

For one, the manifest madness introduced with VS 2005 may be painful to handle, since it severly lacks any serious documentation. I am still unsure whether we will need to care at all, though. Another problem is that python headers are not "clean", they pollute the namespace quite heavily; a new version of python means new names added: those should be trivial, though. Other things are the usual: brokenness of MS tools with respect to standards (basic C99 functions not available, etc...). Every version of MS tool is broken, but in a different way. cheers, David

On Wednesday 08 October 2008 09:40:58 David Cournapeau wrote:

...

How about python 2.5 and numpy 1.2 instead?  Python 2.6 makes some important changes to python 2.5 (in preparation for Python 3.0), so you may find several other packages will take a couple of months to work 100% with python 2.6 - so check this out if you do plan to use more than just numpy.  There are sometimes drawbacks to using brand new releases ;)

If I understand Ravi right, one problem with 2.5 is that it relies on an old toolset (VS 2003, not available anymore). OTOH, 2.6 depends on the most recent toolset, which is also available for free in a limited version (VS 2008 express). If you think about supporting things for a couple of years, relying on VS 2008 sounds safer than 2003.

Absolutely correct. VS 2003 is one of the biggest problems. I know C++ is not a favored language in these parts, but a lot of our code relies on Boost, for platform neutrality (like filesystem, threading, stdint) and for many other utilities (like ublas, wave, tuples, bind). VS 2003 requires too many workarounds in my code and support for it may be dropped in Boost some time soon: VS 7.0 is already scheduled for to be dropped and VS 7.1 (a.k.a. VS 2003) is not likely to be supported for much longer. In fact python 2.5.x's requirement of VS 2003 is probably the main reason that this compiler is still used in a lot of places. The only python packages that I use are numpy/scipy, matplotlib, pyhdf5, and an interprocess communication link with VisIt. To the best of my knowledge, all of these work today (in some fashion) with python 2.6 on Linux. Therefore, any changes required to make them build on Windows are likely to be compiler- specific rather than to fix inherent problems related to python 2.6. Regards, Ravi

On Wednesday 08 October 2008 09:44:25 David Cournapeau wrote:

For one, the manifest madness introduced with VS 2005 may be painful to handle, since it severly lacks any serious documentation. I am still unsure whether we will need to care at all, though.

Another problem is that python headers are not "clean", they pollute the namespace quite heavily; a new version of python means new names added: those should be trivial, though.

Other things are the usual: brokenness of MS tools with respect to standards (basic C99 functions not available, etc...). Every version of MS tool is broken, but in a different way.

The reasons above are why I don't try to do anything on Windows unless there is support from some external source, e.g., CMake taking care of build issues. The reasons above are also why I admire your heroic efforts at making Windows binaries available. But, then, I sometimes wonder about the motivation for an unpaid volunteer to take on an utterly thankless job in which help is never forthcoming from users; for any of my code out in the wild, the only help, bug fixes and improvements I have ever received have been from Linux and Solris users. Thank for taking on this arduous task. Regards, Ravi

Just to note, on the compilation issue, I encountered this a while ago with numpy 1.1.1 and I think Python 2.6b2, again because we wanted to skip Python 2.5 in my organization, largely because it was an issue to get working on 64-bit. I couldn't find anywhere 7.1 was available. We discussed errors you are encountering a few months ago, they are related to the compiler directives.

#ifndef HAVE_FREXPF static float frexpf(float x, int * i) { return (float)frexp((double)(x), i); } #endif #ifndef HAVE_LDEXPF static float ldexpf(float x, int i) { return (float)ldexp((double)(x), i); } #endif

Commenting out this section at line 64 allow compilation and has no ill effects. Hanni 2008/10/8 David Cournapeau

Ravi wrote:

...

The reasons above are why I don't try to do anything on Windows unless

there

...

is support from some external source, e.g., CMake taking care of build issues. The reasons above are also why I admire your heroic efforts at making Windows binaries available. But, then, I sometimes wonder about the motivation for an unpaid volunteer to take on an utterly thankless job in which help is never forthcoming from users;

I think numpy and scipy have a wonderful potential, and that currently, installation is the biggest hurdle. I can show some awesome things in numpy/scipy and co that people used to matlab would only dream of. But if it takes more than 2 minutes and a few clicks to install, it is of no use. I have some people who ask me how to install numpy/scipy, and I have no simple answer: I think this is by far the biggest barrier of entry for numpy and scipy ATM. That's why I am interested in making numpy and scipy installation easy.

...

Thank for taking on this arduous task.

Just want to mention I am certainly not the only one involved here for windows binaries. This is really a collective work,

cheers,

David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Ravi wrote:

Given that commenting out the section above allows numpy to compile without any apparent side effects, is there any chance we could get "experimental" binaries of numpy 1.2.0 for python 2.6? I do understand that a negative answer is very likely and the reasons therefor.

I started a wiki page on the issues related to windows, 64 bits and python 2.6 (those issues are somewhat related at some level): http://scipy.org/scipy/numpy/wiki/MicrosoftToolchainSupport If you want to help, you can try solving one problem. In particular, if you know how to build ATLAS with Visual studio (for 64 bits support), it would be really helpful, cheers, David

Ravi wrote:

Michael Abshoff already responded to the ATLAS question. I don't have access to a 64-bit Windows. Given the volume of legacy 32-bit applications where I work, there is no chance of 64-bit Windows access for me for at least 2 years.

Windows 64 actually has a very nice feature: WoW (windows on windows). It can executes any 32 bits software, AFAIK (which does not run in ring 0 of course).

VS2008 with 32-bit windows should not have any problems (as you mentioned on the Wiki page referenced above).

I wish it were true :) I can't build numpy with mingw ATM, because of bugs in mingw. Things like: http://bugs.python.org/issue3308

What needs to be done to figure out msvc9 support on mingw and how can I help? I am a Windows n00b (mostly by choice) when it comes to platform-specific issues.

Then, I am afraid you won't be of much help, ufortunately. cheers, David

David Cournapeau wrote:

Ravi wrote:

Hi,

...

Michael Abshoff already responded to the ATLAS question. I don't have access to a 64-bit Windows. Given the volume of legacy 32-bit applications where I work, there is no chance of 64-bit Windows access for me for at least 2 years.

Windows 64 actually has a very nice feature: WoW (windows on windows). It can executes any 32 bits software, AFAIK (which does not run in ring 0 of course).

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 :)

...

VS2008 with 32-bit windows should not have any problems (as you mentioned on the Wiki page referenced above).

I wish it were true :) I can't build numpy with mingw ATM, because of bugs in mingw. Things like:

http://bugs.python.org/issue3308

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.

...

What needs to be done to figure out msvc9 support on mingw and how can I help? I am a Windows n00b (mostly by choice) when it comes to platform-specific issues.

Then, I am afraid you won't be of much help, ufortunately.

cheers,

David

Cheers, Michael

_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

David Cournapeau wrote: Hi David,

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.

cheers,

David

Cheers, Michael

_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

David Cournapeau wrote:

Michael Abshoff wrote:

Hi David,

...

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

The biggest problem is that officially, there is still no gcc 4 release for mingw. I saw a gcc 4 section in cygwin, though, so maybe it is about to be released. There is no support at all for 64 bits PE in the 3 serie.

Yes, you are correct and I was wrong. I just checked out the mingw-64 project and there has been a lot of activity the last couple month, including a patch to build pthread-win32 in 64 bit mode.

I think binutils officially support 64 bits PE (I can build a linux hosted binutils for 64 bits PE with x86_64-pc-mingw32 as a target, and it seems to work: disassembling and co). gcc 4 can work, too (you can build a bootstrap C compiler which targets windows 64 bits IICR). The biggest problem AFAICS is the runtime (mingw64, which is indeed legally murky).

I would really like to find the actual reason *why* the legal status of the 64 bit MinGW port is murky (To my knowledge it has to do with taking code from the MS Platform toolkit - but that is conjecture), so I guess I will do the obvious thing and ask on the MinGW list :)

...

Ok, that is a concern I usually do not have since I tend to build my own Python :).

I would say that if you can build python by yourself on windows, you can certainly build numpy by yourself :) It took me quite a time to be able to build python on windows by myself from scratch.

Sure, I do see your point. Accidentally someone posted about http://debian-interix.net/ on the sage-windows list today. It offers a gcc 4.2 toolchain and AFAIK there is at least a patch set for ATLAS to make it work on Interix.

cheers,

David

Cheers, Michael

_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion