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? > 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. I don't think that numpy can be "fixed" in order to solve this problem. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
