Discussion:
[Numpy-discussion] mingw32 and numpy 1.10
Charles R Harris
2015-08-10 22:34:59 UTC
Permalink
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
Nathaniel Smith
2015-08-10 22:53:46 UTC
Permalink
Post by Charles R Harris
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.

I think in this particular case, we should be able to fill in the slot with
an assignment just before calling PyType_Ready?
Post by Charles R Harris
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.

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
Charles R Harris
2015-08-10 23:21:41 UTC
Permalink
Post by Charles R Harris
Post by Charles R Harris
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.
I think in this particular case, we should be able to fill in the slot
with an assignment just before calling PyType_Ready?
Post by Charles R Harris
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.
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.
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

Loading...