Memory fault - core dumped while compiling python 2.2.1 on SCO

[Anton Graph]

Martin v. Loewis wrote:
> Anton Graph <aglyportREMOvethispart at nospam.yahoo.com> writes:
> 
> 
>>python -E setup.py build in gdb:
>>
>>(gdb) where
>>#0  0x80016d06 in do_reloc () from /usr/lib/libc.so.1
> 
> 
> That sounds like a question to bring to an SCO forum. Apparently, this
> crashes when doing relocations while loading the extension
> module. This raises a number of questions:
> 
> - Why does it do relocations at all? Could it be that you have object
>   files that a not position-independent? I.e. is distutils using the
>   compiler correctly both for compilation, and for linking?
> 
>   It might be correct that it tries to perform relocation, e.g. for
>   the global offset table, and the procedure linkage table - but it
>   *is* troubling that relocations is where it crashes.
> 
> - What is the precise version of the operating system you are using?
> 

SCO_SV bongo 3.2 5.0.5 i386

> - I'm troubled by the fact that in both configurations (with an
>   without gcc), the compiler is always referred-to as "cc". Are you
>   sure you are not using gcc?
> 
I'm positive it's SCO cc:

Wed Sep  4 16:17:04 PDT 2002 bongo:/u/src/agl/txb/txt $ gcc -v
Reading specs from /usr/local/lib/gcc-lib/i386-pc-sco3.2v5.0.5/2.95.2/specs
gcc version 2.95.2 19991024 (release)
Wed Sep  4 16:17:07 PDT 2002 bongo:/u/src/agl/txb/txt $ /usr/local/bin/cc
bash: /usr/local/bin/cc: No such file or directory
Wed Sep  4 16:17:14 PDT 2002 bongo:/u/src/agl/txb/txt $ /usr/bin/cc
Usage: cc [ options ] files ...
Wed Sep  4 16:17:18 PDT 2002 bongo:/u/src/agl/txb/txt $ /bin/cc
Usage: cc [ options ] files ...


>   Please have a look at
> 
>   http://gcc.gnu.org/ml/gcc-testresults/1999-04/msg00239.html
> 
>   Notice that the failure mode is quite similar... Likewise,
> 
>   http://www.bitmechanic.com/mail-archives/dbi-users/Jun1999/0485.html
> 
>   reports such a problem when using gcc on SCO.

I see. I doubt the problem is with the compiler though because I have a 
very similar problem with SCO cc. Maybe it's buggy dynamic linker, libs 
or 5.0.5 kernel?


This maybe irrelevant, but
the reason why I thought of migrating to python 2.2.1 was because my 
program linked against python 1.4 libs all of a sudden began to crash in 
memory allocation routines. I linked against Electric Fence and it shown 
a problem caused by this code:
....
PyObject *tuple = PyTuple_New(2);
....
  PyTuple_SET_ITEM(tuple, 1, layout[1]);
^^^^^^^^^^^^^^^^^^^^^^^^^^ bails out with SIGSEGV whenever linked 
against Electric Fence and python 1.4 libs.



Could someone out there tarball Python 2.2.X built on SCO and put it on 
a ftp site?