64-bit python build
tim.one at comcast.net
Tue Aug 27 21:51:19 CEST 2002
> I did a 64-bit build of a recent CVS snapshot on an SGI Octane. It
> worked ok, I just changed the SYSTEM_PAGE_SIZE definition to 16 * 1024
> in obmalloc.c, since this is the page size on 64-bit Irix machines.
I wouldn't bother. The most important thing to note on SGI boxes is that
there's a history of (C) compiler optimization bugs nearly as long as
Python's history. If you're using an SGI compiler, and don't want to spend
a lot of time chasing compiler bugs, you're best off disabling optimization
entirely when building Python.
> bash-2.04# ./python
> Python 2.3a0 (#18, Aug 27 2002, 20:24:55) [C] on irix646
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> sys.maxint
> ... the problem was in test.test_b1, where at line 550 there is:
> list(xrange(sys.maxint / 4))
> I didn't wait long to see if a MemoryError would be catched :) since I
> was running as root, and when a root process on Irix requests for
> memory, you can't know for sure which process will be killed to free
> more RAM... Later on, I ran again as another user, MemoryError was
> raised in test_b1 ok,
What would you like to happen instead when running as root? Is there a way
to rewrite the test to give you the behavior you want, without making the
test useless for other users? Don't answer here <wink>; if this remains
interesting to you, please write it up in a SourceForge report.
> but I got a Bus Error in test_struct ("trying: xcbhilfd").
That smells like a compiler optimization bug; the SGI compiler seems prone
to lifting reads above tests guarding the legality of reads.
> I don't know if there is an interest for 64-bit builds, but if there is,
> I can run more checks and provide any relevant patches at SF. Should I
Sure! Open source is driven by volunteers scratching their own itches -- if
you don't, who will?
More information about the Python-list