Binary compatibility across Python versions?

[Ned Deily]

In article <i2kok1$krp$1 at dough.gmane.org>,
 Christian Heimes <lists at cheimes.de> wrote:
> [Philip Semanchuk wrote:]
> > Specifically, I'm concerned with binaries created by SWIG for a C++  
> > library that our project uses. We'd like to ship precompiled binaries  
> > for Linux, OS X and Windows for Python 2.5 and 2.6. I'm hoping that it  
> > is sufficient to create binaries for each Python for each platform (3  
> > * 2 == 6 total precompiled binaries).
> For each platforms you have to provide binaries for the major CPU
> architectures (X86 and X64_86), too. Users or distributions may compile
> Python with UCS-2 or UCS-4 unicode width. That makes eight different
> binaries for Linux (two version * two archs * UCS2/4). Although most
> distributions follow the LSB standards, binaries aren't necessary ABI
> compatible. C++ binaries tend to break more often than C binaries.

And, on OS X, there are various Python binary distributions in common 
use: the Apple-supplied Pythons (2.5 for OS X 10.5, 2.6 & 2.5 for 10.6), 
the python.org OS X installers for 10.5 and 10.6, plus the ActiveState 
and EPD ones.  It would likely be difficult to ship one binary extension 
that would easily work, if at all, with the most common ones.  For 
instance, the Apple-supplied Python 2.6 is built with gcc 4.2, uses the 
10.6 ABI (SDK deployment target), and x86_64 / i386 / ppc architectures 
(default 64-bit on capable machines).  The python.org 2.6 uses gcc 4.0, 
the 10.4u ABI, and is 32-bit only (i386 / ppc)

-- 
 Ned Deily,
 nad at acm.org