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

[David Cournapeau]

Robert Kern wrote:
> 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?
>   

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