Konrad Hinsen writes:
You'd have to declare PyArray_API static in each module, but that won't be easy as some modules consist of more than one C source file.
All I did was insert a
#define NO_IMPORT_ARRAY
before the #include "arrayobject.h"
in umathmodule.c
I repeated this for all the Packages, and it seems to work just fine.
--Johann
On Tue, 17 Apr 2001, Johann Hibschman wrote:
Konrad Hinsen writes:
You'd have to declare PyArray_API static in each module, but that won't be easy as some modules consist of more than one C source file.
All I did was insert a
#define NO_IMPORT_ARRAY
before the #include "arrayobject.h"
in umathmodule.c
I repeated this for all the Packages, and it seems to work just fine.
--Johann
-- Johann Hibschman johann@physics.berkeley.edu
Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/numpy-discussion
Such a change breaks other platforms...
All I did was insert a
#define NO_IMPORT_ARRAY
That works only if all symbols are globally visible, which is not true on most platforms.
Does anyone know how shared libraries work in detail under MacOS X? Many systems allow the main executable (Python in our case) to choose what symbols are globally visible. Making changes at this level looks like the best solution to me, if possible.
A simple solution would be to change line 262 in Numeric/arrayobject.h from
void **PyArray_API;
to
static void **PyArray_API;
This would break all client modules that consist of more than one source code file and make array-related calls in more than the main file. We have no such modules in the current NumPy, but there might of course be third-party modules out there that are affected.
Another solution would be to add
#define PyArray_API PyArray_API_umath
in module umath just before including arrayobject.h, and add similar lines to other client modules. But this would require a modification to all client modules, including third-party modules, to make them work under MacOS.
Konrad.