Mingw32 will not compile current numpy due to initialization of a static structure slot with a Python C-API function. The function is not considered a constant expression by the old gcc in mingw32. Compilation does work with more recent compilers; evidently the meaning of "constant expression" is up to the vendor. So, this is fixable if we initialize the slot with 0, but that loses some precision/functionality. The question is, do we want to support mingw32, and numpy-vendor as well, for numpy 1.10.0? I think the answer is probably "yes", but we may want to reconsider for numpy 1.11, when we may want to use Carl's mingw64 toolchain instead. Chuck
On Aug 10, 2015 3:38 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
Mingw32 will not compile current numpy due to initialization of a static
So, this is fixable if we initialize the slot with 0, but that loses some
structure slot with a Python C-API function. The function is not considered a constant expression by the old gcc in mingw32. Compilation does work with more recent compilers; evidently the meaning of "constant expression" is up to the vendor. I think in this particular case, we should be able to fill in the slot with an assignment just before calling PyType_Ready? precision/functionality. The question is, do we want to support mingw32, and numpy-vendor as well, for numpy 1.10.0? I think the answer is probably "yes", but we may want to reconsider for numpy 1.11, when we may want to use Carl's mingw64 toolchain instead. While it's obviously not what we want to do in the long run, if these problems turn out to be intractable then yeah, IMO it wouldn't be the end of the world to temporarily give up on providing the sourceforge win32 downloads, given that we already don't provide win64, the current win32 build strategy is almost certainly a dead end going forward, and that win32 and win64 builds are widely available elsewhere. Esp. since time spent trying to keep our win32 builds limping along both delays the release for everyone and wastes time that you could probably find other things to do with... I'm not sure this particular problem is the tipping point, but it's a calculation we should keep in mind. -n
On Mon, Aug 10, 2015 at 4:53 PM, Nathaniel Smith <njs@pobox.com> wrote:
See https://github.com/numpy/numpy/pull/6190. I don't have a problem reinitializing the slot later if that looks like the best way to go. Chuck
participants (2)
-
Charles R Harris -
Nathaniel Smith