[Numpy-discussion] Distutils: using different linker options for c++ and c code

[Robert Kern]

On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> 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