64 bits...

I built 64-bit Python from scratch, but it took a while to get all the commands sorted out:

export SGI_ABI=-64
./configure --prefix=/site/home/mch/opt/python2.4 \
            --with-thread=no --without-gcc --enable-shared
make
make libpython2.4.so
make install

The make libpython2.4.so builds the shared library, which doesn't happen automagically, EVEN THOUGH --enable-shared is given to configure! That is the part I always forget when trying to build a shared Python. There are no threads because I need to run the Python bits in a single thread and let OpenMP take care of all the threading later, so I don't want an extra threading library messing everything up!

Building the Boost.Python libraries can be quite a challenge, mostly because of the bjam system used by Boost. There's probably nothing wrong with the bjam system (at least compared with autotools), I'm just unfamiliar with it. After hours of torture, I found I had to edit pyport.h, which is part of the Python distribution, to get things to work. Specifically, I removed the #includes for time.h so that the definitions for select(...) would stop clashing and added this near the end of the file:

#ifdef __cplusplus
using namespace std;
#endif

That prevented weird errors complaining that the global scope has no "cosl" and other mathy functions.

It was necessary to remove every mention of lib32 from the mipspro-tools.jam file. When lib32 was left in, bjam kept trying to link the 32 bit libraries instead of the 64 bit libraries! I also had to change the "default" abi and arch from -n32 to -64 and -mips3 to -mips4. This isn't really a fix, just a slash-and-burn hack to get 64 bit compilation to work, which is about all I can do at the moment due to my lack of bjam understanding.

Finally, after hours and hours:

export PYTHON_HOME=~/opt/python2.4
export PYTHON_VERSION=2.4
cd ~/Work/boost_1_32_0
bjam "-sBUILD=<address-model>64" -sTOOLS=mipspro \
     --prefix=/site/home/mch/opt/boost --layout=system install

I now have a 64 bit Boost.Python library.

Building Phred to use the shared Python Library turned out to be somewhat unpleasent, because of the wacky LDFLAGS that are required. My configure command line ended up looking like this:

LDFLAGS="-L/site/home/mch/opt/python2.4/lib \
         -Wl,-rpath,/site/home/mch/opt/python2.4/lib \
         -Wl,-rpath,/site/home/mch/opt/boost/lib" \
../Phred-0.1.1/configure --with-cxx=CC --enable-openmp \
    --enable-64bit --with-boost=/site/home/mch/opt/boost \
    --with-python --with-python-libs=/site/home/mch/opt/python2.4/lib/ \
    --with-python-includes=/site/home/mch/opt/python2.4/include

In the end, it did finally compile and it seems to run ok.

Now that Python and Phred are playing nice, I'll have to take a page out of the Origin 2000 and Onyx2 Performance Tuning and Optimization Guide and start looking at the cache behavior. I have a different method of doing loop updates in mind which may or may not be better...

As a side note, here is an interesting article about why LD_LIBRARY_PATH is considered harmful. I used to use it quite a bit because libraries I compile myself on systems I don't have root access to end up in ~/opt/PACKAGE_NAME/lib. Now that I know about the -R flag, I'll use that instead.

The other interesting thing from that article that I didn't know about before is the existance of the LD_RUN_PATH environment variable, which is something I want so that I don't have to add an LDFLAGS to every configure I run. Except LD_RUN_PATH isn't used by IRIX's ld, so it's necessary to use -Wl,-rpath,/path!