Fernando Perez wrote:

Zachary Pincus wrote:

...

I've seen this too, and been able to fix it by removing the build directory and rebuilding everything.

I wonder if there's a bug in numpy's dependency checking that's causing certain files to not get rebuilt when they ought. I recently updated to the SVN head, and numpy segfaulted on import, just as you describe. After puttering around with GDB, it looked like some of the code was out of synch with other parts of the code, so I decided to rebuild from scratch.

After I deleted the entire numpy build directory ('python setup.py clean' *did not* work) and re-built, things worked just fine. I've also had this problem with scipy, and the same solution applied.

Anyhow, try removing all traces of build products from the numpy directory and rebuilding... maybe that will fix things.

Just a hint from experience: do NOT trust distutils to do proper dependency management and know what to rebuild and what not to.

Generally it does an okay job, I think. numpy does quite a lot with generated code, however, and distutils *does* have a hard time with that. Unfortunately, I don't think there is much we can do about that without replacing even more of distutils.

Most of us have settled on some variation of:

...

With that, I can just type

./makepkg numpy

or

./makepkg scipy

and I'm almost sure it will do the right thing.

I wonder if we shouldn't add this to the wiki as the recommended procedure for builds (at least under *nix). I know it allows me to do fresh svn builds of numpy/scipy at any time without having to think (a process rarely successful within the confines of my skull).

+1. At least until 1.0 when the C API settles down. -- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

Travis Oliphant wrote:

Tim Hochberg wrote:

...

I just updated from CVS and compiled using VC7. The resulting numpy segfaults immediately on import. Do not pass go, do not collect $200. It's been a couple of weeks probably since I updated from CVS, so I'm not sure where to start looking. I suppose I could start going back in time until it works again and then see what checkins broke it, but if anyone has any better ideas, let me know.

You definitely need to remove your build directory. It is a build dependency issue (some needed generated code is not getting rebuilt when it should be). I'm not sure how to fix it, so I remove the build directory.

It shows up when the C-API changes more significantly then just appending new C-API calls. It changed significantly recently as I moved the version checking C-API to the very front (so it won't move around in the future -- no matter what is done to the C-API), and I added the fixed Boolean array scalar True and False objects.

The segfaults in scipy should disappear upon rebuild of numpy because the C-API now has the version checking at the very start and will gracefully exit with an error rather than rudely segfault.

This did fix things...eventually. I removed the build directory and rebuilt. Numpy still bombed the interpreter, although in a new and less exciting way. I then did a clean checkout from svn and rebuilt. Same thing. Then I manally removed numpy from site-packages and reinstalled at which points things worked and all tests passed. So in addition to needing to remove the build directory, it appears that something was hanging out in the destination directory that did not get overwritten and caused problems. Perhaps this description will help the next person who runs into this, but probably not. -tim

Fernando Perez wrote:

Tim Hochberg wrote:

...

This did fix things...eventually. I removed the build directory and rebuilt. Numpy still bombed the interpreter, although in a new and less exciting way. I then did a clean checkout from svn and rebuilt. Same thing. Then I manally removed numpy from site-packages and reinstalled at which points things worked and all tests passed.

So in addition to needing to remove the build directory, it appears that something was hanging out in the destination directory that did not get overwritten and caused problems.

Perhaps this description will help the next person who runs into this, but probably not.

Well, the script that I posted does precisely all of this in a mindless fashion,

So it does. I should have looked at that more closely.

which is why I find it useful. You may want to give it a try (it's trivial, but it just ensures you don't forget these steps and end up wasting any time chasing the problem).

Well, I'd probably have to rewrite it to get it work under windows. I may do that, although 'rm -rf' always scares me (even though it looks pretty safe here). Still, it would be nice if 'setup.py clean' and 'setup.py install' did this automagically. -tim

Cheers,

f