On Feb 1, 8:57am, Greg Ward wrote:
Subject: Re: [Distutils] Complling on IRIX OS On 27 January 2000, Curtis Jensen said:
To install on an IRIX OS, sometimes we need to compile with the -o32 flag. I can't seem to find how to do this with distutils. Any ideas?
Hmmm... I just checked the source, and it looks like there is no way to do this right now. ;-( Why do you need to? The Distutils default -- in fact, its *only* behaviour for now -- is to compile extensions the same way you compiled Python itself. I'm a bit fuzzy on the various 32/64 options for the IRIX 6+ compiler, but I expect you'd have a hard time loading .so's compiled one way into an executable compiled another way. What exactly are you trying to accomplish here -- better performance, ability to run on more platforms (ie. 32- and 64-bit IRIX), or what?
Greg, sgi has created a real mess. They have 3 ABIs (Application Binary Interfaces): IRIX supports three ABIs: o32 The old 32-bit ABI which was standard on IRIX 5 systems. n64 The 64-bit ABI which was introduced on IRIX 6.0 systems. n32 The new high performance 32-bit ABI which was introduced on IRIX 6.2. Of course objects using a given ABI cannot be mixed. As long as one compiles extensions on an SGI running the same OS as the one the Python interpreter has been compiled on AND one uses default compilation flags everything works fine. Unfortunately this is not the always the case. I compile everything by explicitly specifying -o32 -mips2 in the compilation flags and -o32 in the LDFLAGS. This ensures maximum portability between various SGI configurations. Are you saying that it would difficult to specify at build time that I want these flags to be added to CPFLAGS and LDFLAGS ? or is the problem to find out "automatically" whether the Python interpreter running disutil was built o32 n32 or n64 ? For the second option, one could simple execute a "file" unix-command on the python binary to find out about the ABI. -Michel -- -----------------------------------------------------------------------
>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!
Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner@scripps.edu http://www.scripps.edu/sanner -----------------------------------------------------------------------
Michel Sanner wrote:
Greg, sgi has created a real mess. They have 3 ABIs (Application Binary Interfaces):
IRIX supports three ABIs:
o32 The old 32-bit ABI which was standard on IRIX 5 systems.
n64 The 64-bit ABI which was introduced on IRIX 6.0 systems.
n32 The new high performance 32-bit ABI which was introduced on IRIX 6.2.
Just in case this hasn't come up yet: you can check for o32, n64 and n32 using the architecture() API in platform.py (available from my Python Pages). Other goodies in platform.py might also help to set some reasonable default options for other platforms as well. FYI, platform.py provides a platform independent way of querying platform dependent data... (well, look at the code then you'll know what I mean ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On 01 February 2000, Michel Sanner said:
Greg, sgi has created a real mess. They have 3 ABIs (Application Binary Interfaces): [...]
Thanks for the explanation.
Of course objects using a given ABI cannot be mixed. As long as one compiles extensions on an SGI running the same OS as the one the Python interpreter has been compiled on AND one uses default compilation flags everything works fine.
That's what I suspected -- eg. if your python is built -n32, you can't link on extensions built with -n64 or -o32.
Are you saying that it would difficult to specify at build time that I want these flags to be added to CPFLAGS and LDFLAGS ?
Stop thinking in terms of CFLAGS and LDFLAGS -- they no longer exist. There are no makefiles. (We have always been at war with Oceania.) Conceptually, though, yes: it would be quite difficult to augment the compiler/linker flags that Distutils uses when building extensions, because I forgot to provide a "way in" for either module developers or installers to provide this information. That's needed for fairly innocuous cases -- eg. compile this big file with -Olimit=1500 (another annoying SGIism) -- or for people who enjoy playing with fire (try to mix and match -o32 and -n32 between python and an extension). Both of these should be supported, the former because it's necessary, the latter because people should be given the freedom to shoot themselves in the foot if they really insist. Might be nice to add a warning to the effect that "compiler flags differ -- if things blow up, don't blame me" though.
or is the problem to find out "automatically" whether the Python interpreter running disutil was built o32 n32 or n64 ? For the second option, one could simple execute a "file" unix-command on the python binary to find out about the ABI.
Eew, that's getting awfully platform-specific. What I prefer to do is just use the compiler flags used to build Python. That'll work most of the time; the only time it'll really fall down is for that big file that requires -Olimit=1500 on IRIX, or some other funky thing on other compilers. Another possibility: hairy code that confuses gcc's optimizer, so you need one of the -f switches to turn off that type of optimization for that file. One could imagine endless perverse examples, but it boils down to this: * the user (either module developer or installer) needs a way to circumvent the lovely platform-neutral compiler abstraction model, and just say, "on platform X, with compiler Y, shove *these* flags in when you run the compiler (and *these* other flags when you run the linker). It's crude, it's ugly, but it's essential. Incidentally, if you think you need this backdoor to (eg.) define a preprocessor macro or add another include directory for a particular C source file, think again: these things *are* handled by the lovely platform-neutral compiler abstraction model, because those are essential attributes of the language itself. Cranking up an optimization buffer, or turning off loop-unrolling, are inextricably linked to a particular compiler (often on a particular platform), so have no place in that abstraction model. Hence the occasional need for a backdoor. Greg
participants (3)
-
Greg Ward
-
M.-A. Lemburg
-
Michel Sanner