[Numpy-discussion] Updates on using recent mingw for numpy/scipy

[Matthew Brett]

Hi David,

Thanks a lot for the update.

On Tue, Nov 5, 2013 at 10:50 AM, David Cournapeau <cournape at gmail.com> wrote:
> Hi there,
>
> During pycon.fr sprints, I took some time to look more into building
> numpy/scipy wheels on windows with recent mingw (gcc 4.x series).
>
> tl;dr: While I made some progress, there remains some hard-to-track issues.
> I will prepare a vagrant setup so that other people can work on this as well
> so that I don't remain the bottleneck.
>
> details:
>
>  - all the tests were done on 32 bits. While 64 bits would add some
> challenges, I think most mingw-specific issues are independent of 32 vs 64
> bits.
>  - works mean building + running numpy/scipy.test() without 'bad' failures
>  - compiling numpy without any blas/lapack, but completely static (no
> dependency on mingw at runtime) works with both mingw-w64 and mingw.
>  - compiling numpy with a custom-built blas/lapack 3.4.2 gives me a working
> numpy with mingw, but mingw-w64 gives a very weird failure: importing numpy
> once segfaults at some location, twice at a difference one, three times at
> yet another one, and then never segault anymore (unless I build a new one or
> reboot windows). I suspect some weird runtime interactions.
>  - compiling scipy with mingw + custom-built blas/lapack works, except that
> it crashes when exciting the process (with some C runtime-related errors).
>  - compiling both numpy and scipy without statically linking gfortran
> runtime does work.
>
> I am hoping that those errors are caused by some invalid link order. As
> controlling those precisely with distutils is horrible, I have not been able
> to pursue this any further.

Can the build problems be addressed by using waf / bento?

Cheers,

Matthew