64-bit python build

[Tim Peters]

[Christos TZOTZIOY]
> 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
> 9223372036854775807
> ...
 > ... 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
> bother?

Sure!  Open source is driven by volunteers scratching their own itches -- if
you don't, who will?