[SciPy-dev] newscipy segfaults fixed!
oliphant at ee.byu.edu
Tue Oct 18 18:36:50 CDT 2005
Pearu Peterson wrote:
>On Tue, 18 Oct 2005, Travis Oliphant wrote:
>>Pearu Peterson wrote:
>>>The segfaults in newcore hava now a fix in SVN. Currently scipy.test()
>>>gives more than 200 errors, but they should go away as soon as newscipy
>>>packages have been ported to newcore.
>>Did you find a fix for the PyArray_FromDims problem? I have not had
>>time to track this down, but can later.
>Yes, it turns out that if a source file like fortranobject.c uses newcore,
>some function must call import_array() to set PyArray_API. I did that by
>introducing init_fortranobject() function that only calls import_array()
>and the extension module calls init_fortranobject() from the module init
>function. This was not needed in Numeric.
>Hmm, may be PyArray_API should not be defined as static. Is there a reason
>that PyArray_API must be defined static?
Wait a minute.... PyArray_API is defined exactly the same way the
Numeric defined it. It's static (and filled by import_array) unless
PY_ARRAY_UNIQUE_SYMBOL is defined or NO_IMPORT or NO_IMPORT_ARRAY is
So, the thing to do is compile fortranobject.c with NO_IMPORT_ARRAY
defined (that way PyArray_API is declared extern), and define
PY_ARRAY_UNIQUE_SYMBOL to be <whatever>, and then compile the extension
modules that want to use fortranobject.c code by defining
PY_ARRAY_UNIQUE_SYMBOL to be <whatever>.
This was the same way you had to do it in Numeric. So, I don't see
I did, however, recently add to newcore NO_IMPORT to be equivalent to
NO_IMPORT_ARRAY. Perhaps f2py was defining NO_IMPORT instead of
NO_IMPORT_ARRAY. This would have worked with Numeric, but not newcore
(until recent SVN checkin).
More information about the Scipy-dev