binary builds against older numpys
We are trying to build and test mpl installers for python2.4, 2.5 and 2.6. What we are finding is that if we build mpl against a more recent numpy than the installed numpy on a test machine, the import of mpl extension modules which depend on numpy trigger a segfault. Eg, on python2.5 and python2.6, we build the mpl installers against the numpy-1.3.0-win32.superpack installation, and if I test the installer on a python2.5 machine with numpy-1.2.1-win32.superpack installed, I get the segfault. If I install numpy-1.3.0-win32.superpack on the test machine, then the mpl binaries work fine. Is there an known binary incompatibly between 1.2.1 and 1.3.0? One solution we may consider is building our 2.5 binaries against 1.2.1 and seeing if they work with both 1.2.1 and 1.3.0 installations, but wanted to check in here to see if there were known issues or solutions we should be considering. Our test installers are at http://drop.io/rlck8ph if you are interested. Thanks, JDH
On Wed, May 20, 2009 at 3:07 PM, John Hunter <jdh2358@gmail.com> wrote:
We are trying to build and test mpl installers for python2.4, 2.5 and 2.6. What we are finding is that if we build mpl against a more recent numpy than the installed numpy on a test machine, the import of mpl extension modules which depend on numpy trigger a segfault.
Eg, on python2.5 and python2.6, we build the mpl installers against the numpy-1.3.0-win32.superpack installation, and if I test the installer on a python2.5 machine with numpy-1.2.1-win32.superpack installed, I get the segfault. If I install numpy-1.3.0-win32.superpack on the test machine, then the mpl binaries work fine.
Is there an known binary incompatibly between 1.2.1 and 1.3.0? One solution we may consider is building our 2.5 binaries against 1.2.1 and seeing if they work with both 1.2.1 and 1.3.0 installations, but wanted to check in here to see if there were known issues or solutions we should be considering.
Our test installers are at http://drop.io/rlck8ph if you are interested.
Thanks, JDH
A few days ago, I asked the same question for scipy in scipy-dev, since I got segfaults using scipy against an older numpy version than the one it was build against. Davids reply is that there is no forward compatibility. Josef
Hi John 2009/5/20 <josef.pktd@gmail.com>:
On Wed, May 20, 2009 at 3:07 PM, John Hunter <jdh2358@gmail.com> wrote:
We are trying to build and test mpl installers for python2.4, 2.5 and 2.6. What we are finding is that if we build mpl against a more recent numpy than the installed numpy on a test machine, the import of mpl extension modules which depend on numpy trigger a segfault.
I think we accidentally forgot to increase the API version at some stage (bad), but we now have checks in place to catch these mismatches. Specifically, import_array makes sure that the ABI versions agree, and that the API is the same or newer: if (NPY_VERSION != PyArray_GetNDArrayCVersion()) { PyErr_Format(PyExc_RuntimeError, "module compiled against "\ "ABI version %%x but this version of numpy is %%x", \ (int) NPY_VERSION, (int) PyArray_GetNDArrayCVersion()); return -1; } if (NPY_FEATURE_VERSION > PyArray_GetNDArrayCFeatureVersion()) { PyErr_Format(PyExc_RuntimeError, "module compiled against "\ "API version %%x but this version of numpy is %%x", \ (int) NPY_FEATURE_VERSION, (int) PyArray_GetNDArrayCFeatureVersion()); return -1; } David Cournapeau also put a check in place so that the NumPy build will break if we forget to update the API version again. So, while we can't change the releases of NumPy out there already, we can at least ensure that this won't happen again. Regards Stéfan
2009/5/20 Stéfan van der Walt <stefan@sun.ac.za>:
David Cournapeau also put a check in place so that the NumPy build will break if we forget to update the API version again.
So, while we can't change the releases of NumPy out there already, we can at least ensure that this won't happen again.
OK, great -- thanks for th info. From reading David's comments in the earlier thread: David > - Backward compatibility means that you can build something against David > numpy version M, later update numpy to version N >M, and it still works. David > numpy 1.3.0 is backward compatible with 1.2.1 it looks like our best bet will be to build our python2.4 and python2.5 binaries against 1.2.1 and our python2.6 binaries against 1.3.0 (since there are no older python2.6 numpy builds on the sf site anyhow). I'll post on the mpl list and site that anyone using the new mpl installers needs to be on numpy 1.2.1 or later. JDH
Stéfan van der Walt wrote:
Hi John
2009/5/20 <josef.pktd@gmail.com>:
On Wed, May 20, 2009 at 3:07 PM, John Hunter <jdh2358@gmail.com> wrote:
We are trying to build and test mpl installers for python2.4, 2.5 and 2.6. What we are finding is that if we build mpl against a more recent numpy than the installed numpy on a test machine, the import of mpl extension modules which depend on numpy trigger a segfault.
I think we accidentally forgot to increase the API version at some stage (bad), but we now have checks in place to catch these mismatches.
Yes, we did forget this, but it would not have solve the problem. Building against a version N of numpy and running under a version M < N is not supported at all. We explicitly check for it starting for numpy 1.4.0, but it does not affect the solution, that is building against the oldest version possible. This rule is the same for almost any library, and not specific to numpy, or even python extensions. David
participants (4)
-
David Cournapeau -
John Hunter -
josef.pktd＠gmail.com -
Stéfan van der Walt