[Numpy-discussion] Binary releases
Charles R Harris
charlesr.harris at gmail.com
Mon Sep 16 19:55:35 EDT 2013
On Mon, Sep 16, 2013 at 12:31 PM, David Cournapeau <cournape at gmail.com>wrote:
> On Mon, Sep 16, 2013 at 7:19 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>> On Mon, Sep 16, 2013 at 12:12 PM, David Cournapeau <cournape at gmail.com>wrote:
>>> On Mon, Sep 16, 2013 at 4:36 PM, Charles R Harris <
>>> charlesr.harris at gmail.com> wrote:
>>>> New summary
>>>> 1. 32 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC
>>>> 2. 64 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC,
>>>> linked with MKL
>>>> These should be good for both windows 7 and window 8.
>>> Wait, when was it decided to move to MSVC for the official binaries ?
>>> Especially using ifort/MKL on windows means it will be difficult for other
>>> projects to produce packages on top of it.
>> It hasn't been decided, this is just a modified version of the initial
> ok, sorry for the confusion
>> Why not use MSVC? python.org does. What is the problem with statically
>> linked MKL? Do other packages need to link to lapack? The windows build
>> problem has hung around for years. I'm tired of it.
> Which build problem ? Being tired of it does not justify a decision in
> particular, otherwise we fall into the fallacy "there is a problem,
> therefore we must do something". There are multiple issues:
> - moving away from gcc 3.x on 32 bits. Those compilers are old, but it
> works well today. It is an untenable situation in the long term, though. I
> will look again at building numpy/scipy with mingw-w64 in 32 bits to see if
> the problems with -static-* are gone or not.
> - 64 bits support: linked to first point. If the first point is solved, I
> am relatively confident this one can too.
> - moving away from Atlas to MKL: this is much more problematic. First,
> MKL is *huge*. For info, the MKL package we provide @ Enthought is 70 MB
> zip compressed, and that's for the DLLs. The static version may be even
> - using ifort for fortran: by doing this, we impose on *every* package
> downstream to use ifort as well (same for MKL BTW).
> There is also the issue of a blas/lapack for windows 64 bits. There the
> situation has changed a lot since I last looked into those issues: cygwin
> (required by atlas) now supports 64 bits natively, and openblas is
> relatively well supported. I would certainly be happy to get rid of ATLAS
> which is a PITA to maintain, and use openblas instead.
Openblas includes some of lapack and is available for x86_64 on windows. It
isn't clear what is included nor what compiler was used.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion