On Apr 15, 11:33 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > What is Py_UNICODE_SIZE and why was it not defined? There are current
> > questions I have.
>
> Py_UNICODE_SIZE is the number of bytes that a Py_UNICODE value should
> have in the interpreter. With --enable-unicode=ucs2, it should be 2.
Martin,
Thanks for your reply. I feel like a dummy, when I was following Marc-
Andre's instructions I incorrectly typed "--enable-
unicode=ucs24" (note the "4"). Once I fixed that the Py_UNICODE_SIZE
issue went away.
Alas, I still am having problems compiling and getting a clean run
through make test. I got this error:
Python-2.5.2/Modules/bz2module.c:12:19: error: bzlib.h: No such file
or directory
Which I solved by copying bzlib.h I have on the system to Python-2.5.2/
Include/.
The run of make test resulted in this error:
test_ctypes
find_library('c') -> None
find_library('m') -> None
make: *** [test] Segmentation fault (core dumped)
An examination of the core with gdb shows this:
$ gdb python core
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
[snip]
This GDB was configured as "powerpc-ibm-aix5.2.0.0"...
Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0 0xdebccc5c in ffi_closure_helper_DARWIN (closure=0xdebcd050,
rvalue=0x2ff20230, pgr=0x2ff20258, pfr=0x2ff201c8)
at Python-2.5.2/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:
626
626 avalue = alloca(cif->nargs * sizeof(void *));
(gdb) bt
#0 0xdebccc5c in ffi_closure_helper_DARWIN (closure=0xdebcd050,
rvalue=0x2ff20230, pgr=0x2ff20258, pfr=0x2ff201c8)
at Python-2.5.2/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:
626
#1 0xdebcd2bc in ffi_closure_ASM () from build/lib.aix-5.2-2.5/
_ctypes.so
#2 0xdebcd458 in ffi_call_AIX () from build/lib.aix-5.2-2.5/
_ctypes.so
#3 0xdebccf24 in ffi_call (cif=0xdebcd050, [EMAIL PROTECTED]:
0x2ff20350,
rvalue=0x2ff20258, avalue=0x2ff201c8)
at Python-2.5.2/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:
421
#4 0xdebcb5e8 in _CallProc ([EMAIL PROTECTED]: 0xdebcd248
<ffi_closure_ASM>,
argtuple=0x20d5e9ac, flags=4097, argtypes=0x20d5eb2c,
restype=0x20e7dc44,
checker=0x0)
at Python-2.5.2/Modules/_ctypes/callproc.c:668
[snip frames #5 to #55]
#56 0x10063a70 in PyEval_EvalCode (co=0xdebcd050, globals=0x2ff20230,
locals=0x2ff20258) at Python/ceval.c:494
cals=0x2ff20258) at Python/ceval.c:494
(gdb) print cif
$1 = (ffi_cif *) 0x140
(gdb) print *cif
$3 = {abi = 1600485481, nargs = 1946157056, arg_types = 0x0, rtype =
0x400a,
bytes = 1, flags = 0}
Thus it would seem use cif here resulted in a segment violation. I'll
continue to research this issue and report back to the group as I know
more. Perhaps solving the issue with the 'c' and 'm' libraries
(whatever they might be) will make the core dump go away. However,
for tonight, I'll need to stop here.
Kind regards,
-Randy Galbraith
--
http://mail.python.org/mailman/listinfo/python-list
