[Distutils] Complling on IRIX OS

Greg Ward gward@cnri.reston.va.us
Tue, 1 Feb 2000 13:21:33 -0500


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