Hi, Great, my long tested program works now again. I still don't know what the gcc option -fPIC is for. Also "-shared" is not clear to me. (From the discussion before: I don't use it, seg-fault if I do) I anyone here could teach me ... In any case, I'm happy again. Thanks, Sebastian Haase On Thursday 02 June 2005 16:11, Adrian E. Feiguin wrote:
Hi Todd,
I compiled the cvs version and it seems that you have fixed the problem, excellent! However, your "fix" for older versions doesn't work, any suggestions?
Thanks! <ADRIAN>
Todd Miller wrote:
I looked over your diffs but I don't think they're related to the problem you're seeing.
From your previous posts and those of Sebastian, I had the impression
that you're using numarray in an embedded context... so I found embedded "from numarray import *".
I learned that numarray embedding "broke" for numarray-1.2.3 by adding the unnecessary requirement that sys.argv exist. I fixed this in numarray CVS. A possible alternative to my fix which should work for older versions of numarray is to call PySys_SetArgv(0,NULL) after Py_Initialize() to ensure that sys.argv exists.
Regards, Todd
On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote:
Hi,
As I've been discussing withTodd, scigraphica crashes after switching to a newer version of numarray. I checked that it does not crash with Numeric, or numarray-1.1.1, so I figured that at some point something was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 some change broke the API. What I mean is that my libraries simply fail to load numarray. I did diff between headers, and the only relevant change that I noticed between 1.1.1 and 1.2.3 that I guess could be related to this problem is in libnumeric.h:
132c132 < static int PyArray_Converter (PyObject *, PyObject **); ---
static int XXX_PyArray_Converter (PyObject *, PyObject **);
140c140 < static int PyArray_ValidType (int type); ---
static int XXX_PyArray_ValidType (int type);
208c208 < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject **) ) libnumeric_FatalApiError)) ---
#define XXX_PyArray_Converter (libnumeric_API ? (*(int (*)
(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject **) ) libnumeric_FatalApiError)) 216c216 < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) ---
#define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int
type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError))
I hope this helps. I'll work with 1.1.1 from now on, unless you think the problem is in my code. Any ideas? Thanks <ADRIAN>
Todd Miller wrote:
Hi Adrian,
I don't think you should be doing both "import_array()" and "import_libnumeric()". Those should be roughly equivalent. If you're using only the Numeric compatible API (no NA_ functions) then do:
#include "numarray/arrayobject.h"
... and later in your init function:
import_array();
just like Numeric. If you also need some of the NA_ functions, then look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface with both native and numeric compatible interfaces at the same time. If you only need NA_ functions, look at Src/_ndarraymodule.c.
Regards, Todd
On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote:
Hi Todd,
Thank you for your reply. I have a completely new installation, there are no conflicts with previous installations. I found that the problem is in import_libnumeric in libnumeric.h. It seems that the libnumeric_API is not initialized because it doesn't pass the line:
PyObject *module = PyImport_ImportModule("numarray.libnumeric"); \ if (module != NULL) { \
Any ideas? Thank you again, <ADRIAN>
Todd Miller wrote:
Hi Adrian,
On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >Hi! I'm the lead developer of scigraphica (SG) >http://scigraphica.sourceforge.net and I'm using python and numarray > to parse math. SG is built on top of libscigraphica, and > libscigraphica has all the python code. I've been using an old > version 0.6.1, and everything worked fine. After switching to > 1.6.2the program crashes. I'll give you some info to see if you can > tell me what's wrong: > >I'm using: >#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >#include
> >and in the code: > import_libnumeric(); > import_array(); > > object=PyRun_String ("from numarray import *", Py_single_input, >main_dict, sg_dict); > >(I noticed that you have to add import_libnumeric now) In general, this is not true.
Paradoxically, if you're using the numeric compatible API, import_array() is all you need to do. If you're using both the numarray native and numeric compatible APIs, then you need to import_libnumarray() and import_libnumeric().
>The gdb output is: > >Importing python module: sys >Importing python module: pickle >Importing python module: os >Importing python module: numarrayProgram received signal SIGSEGV, >Segmentation fault. >[Switching to Thread 1083181376 (LWP 11648)] >0x400ab0b5 in PyObject_GetAttrString () > from >/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigrap >hica-2.0-2.0.so.0 #0 0x400ab0b5 in PyObject_GetAttrString () > from >/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigrap >hica-2.0-2.0.so.0 #1 0x40b1ff66 in deferred_libnumarray_init () at >Src/libnumarraymodule.c:152 >#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at > Src/libnumarraymodule.c:1357 #3 0x40b43c1c in PyArray_Check > (op=0x0) at Src/libnumericmodule.c:216 #4 0x4004d903 in > python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > at sg_python_worksheet.c:802 >#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > at sg_python_worksheet.c:843 >#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, > col=0, text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > #7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, > data=0x81ba4e0) at sg_worksheet.c:439 > >Look that in #4 object=0x80bda3c, and in #3 op=0x0. >Any hints?
numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 you should:
a. completely delete your numarray installation
b. reinstall numarray
c. rebuild and reinstall any extensions based on numarray.
My guess is that either you have overlapping/conflicting numarray installations or you have extensions from numarray-0.6.1 trying to run against numarray-1.3.2.
Regards, Todd
.
------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
.
------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion