Memory fault - core dumped while compiling python 2.2.1 on SCO

Anton Graph aglyportREMOvethispart at
Wed Sep 4 20:11:37 EDT 2002

Martin v. Loewis wrote:
> Anton Graph <aglyportREMOvethispart at> writes:
>>python -E build in gdb:
>>(gdb) where
>>#0  0x80016d06 in do_reloc () from /usr/lib/
> 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
>   Notice that the failure mode is quite similar... Likewise,
>   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?

More information about the Python-list mailing list