Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the <<prefix.>/python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files.
Logged In: YES user_id=88015 Ok - to fix this *particular* part of the problem turns out to be simple. (I had tried setting MACHDEP in my environment, but that fails as, if MACHDEP is set, then the configure script does not set ac_sys_system and ac_sys_release so tests on these fail to get done). So, attached is the patch which equates the two. NOTE: There are other build problems. The SGI C linker (and OSF1) uses -rpath not -R, and the extension buuilding scripts don't knwo how to handle this...but I suppose these would be for a different bug report.
