The specs of my machine.

Hello again,

I just thought it might be productive, for me to summarize more
comprehensively what kind of machine I have. One reason is the
possibility, that something which I see not working on mine, might be
working well on other machines. However in such a case, it would strike
me as more likely that I'm missing a (Python) dependency (in this most
recent case) somewhere.

I have more than one computer in my computer room, and actually give a
name to each computer. However this practice of mine isn't received well
by other people, even though these names are actually the LAN network
names of the machines. But fortunately, I've only tried to compile
"Cinepaint 0.25.0" on one machine.

This machine has kernel version '2.6.32-9-generic', and is actually
running a version of "Kanotix: Thorhammer".  Kanotix builds are based on
Debian, although this particular team of developers puts a Ubuntu kernel
(obviously recompiling it) onto a rather ordinary Debian system of
packages. Thus, Kanotix kernels generally tend to be ahead of the Debian
build, even if they are not being taken from Ubuntu for a change. The
repositories are true-blue Lenny, although Kanotix has a few
repositories of its own in '/etc/apt/sources.list' .  Those Kanotix
repositories only supply a few special features and their contributed
packages are extremely small in number. It's similar to how I just add
"Virtual Box" to my Debian sources.list :  It won't really interfere
with much.

I have an 'Intel i950' chip-set to contend with, for which reason I'm
not expecting this machine to get far with 3D graphics of any sort. But
2D graphics it's capable of, and is even capable of rendering some 3D
using the various OpenGL drivers, because Kanotix happens to recognize
the i915 chip-set. Hence, OpenGL will run, but without much of the
shader support etc., which people commonly expect these days (including
myself). This was an office box, which I received used and wiped. When I
run glxinfo, it lists 'Direct Rendering = Yes' but as a trade-off, I've
only got OpenGL 1.3 or some such thing, while with real graphics
hardware I'd have 2.2.x ...

I only have 512MB of RAM for the moment, although that could change some
day, and it's running dual-channel at 400MHz. The CPU is an
early-generation Intel Dual-Core running at 3.0GHz, and performing by
giving me a lot of noticeable speed.

I'm on KDE 3.5.10 ,  and using Python 2.5 .

Okay. But because I've heard of the error before, in which the Python
interpreter quits with such a glibc-caught invalid pointer to its own
internal free() function, I'm still more likely to suspect that one
coder wrote a Python function which returns no value, and that another
coder somewhere else is assigning an *assumed* return value to a
variable. If the code cannot get a return value from the function
indicated, then it will get that return value from somewhere else, or so
the argument goes. My guess is that because the return values are passed
via register or reserved location, in contrast to parameters which are
passed on the stack, the return value which gets assigned to the
variable in such a scenario may simply be whatever value happened to be
in said register from before. This type of value is also known as "garbage".

I have libstdc++ version 4.3.2-1.1, and my glibc version only seems to
be weakly hinted as ?2.7?  We don't need to have glibc installed as a
separate package, but the stdc++ libraries were statically liked to it
by the package builders. And the glibc version which was once used is no
longer part of the package name. However, packages 'libc6' and
'glibc-doc' are version "2.7-18lenny2" .

Because I have over 2200 packages installed, it would be kind of useless
to try to summarize which ones are included. Yet, if there is some
specific Python dependency which might be relevant to my problem, you
could try to point it out to me.

Dirk

-- 
You can visit my CGI at:

http://www.dirkmittler.net/GallIndex.htm
(Spelled ... lower-case el - el - Capital Eye ... ndex.htm) 


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev