Robert Kern wrote: > On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau > <[EMAIL PROTECTED]> wrote: > >> Robert Kern wrote: >> > >> > Ah, this problem again. The build of mingw that you are using were >> > written with msvcrt in mind. For the most part they are compatible >> > with msvcr71, but there are a few places where they reference a table >> > that is different between the two runtimes, namely iostream in C++ and >> > ischar() in C. >> >> Do you know by any chance any document/email which talks about that ? >> The only things I found were very general (I know file related do not >> work, but that's it). >> > > Only my own emails. I found this out by largely experimentation and > reading the header files. > > >> > Consequently, there are some extension modules built >> > with mingw which work with msvcrt because they need iostream, some >> > with msvcr71 because they need to pass FILE pointers, and probably >> > some which won't work with either. The core problem won't be fixed >> > until mingw writes their headers for msvcr71. They may have; it looks >> > like they just released some new builds this month. It would be worth >> > checking these out. >> >> Are you talking about the 3.* or the 4.* releases ? >> The new 3.* release seems to only contain a new release note (all the >> files except the release note have 20060117-2 in their names). >> > > Ah, I missed that. It looks like it's just a re-release of the 2006 > build with a bugfix for Vista. > > >> I also found an unofficial installer for gcc 4.*, which at least claim >> to care about python: >> >> http://www.develer.com/oss/GccWinBinaries >> >> The problems with the new official (but beta) 4.* builds is the lack of >> fortran support. For some reasons, building gfortran on windows does not >> sound really appealing :) Also, I noticed when developing numscons that >> numpy (implicetely ?) relied on buggy mingw headers, bugs which were >> fixed in 4.* and hence did not work forr numpy (nothing serious, though; >> it should be easily fixable in distutils). >> > > What were these problems? >
Distutils uses some tests function to see wether a particular set of float functions is available (FUNCTIONS_TO_CHECK dict in numpy/core/setup.py), detects a particular set is not available on mingw (say 'HAVE_INVERSE_HYPERBOLIC'), and define all of them. The problem is that they are available in the library, just not declared (I remember because at first, when I built the core with numscons, I only detected functions by linking to them, and I had discrepancies between numscons config.h and distutils config.h: that's why I now use both declaration and presence detection in the m library). Concretely, some redefinition from static to non static; but that's just a configuration problem I think. > >> Thank you for those information, I will dig a bit deeper. Should we >> consider this as a major blocker for numpy as well (since it would not >> be possible to build a working scipy with numpy 1.1.0 ?) ? >> > > It depends entirely on what the ultimate solution is. Yes. I still hope this can be solved using a different build chain than the 3.4.5 mingw. If not, there is nothing we can do about it. But then, should we build official binaries with MS compilers ? cheers, David _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
