Binary compatibility across Python versions?

[Philip Semanchuk]

On Jul 26, 2010, at 5:19 PM, Ned Deily wrote:

> 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)

Thanks to all who replied on this topic. A little more background --  
these binaries are just a convenience for our users and we don't have  
to cover every possible permutation of Python, only the ones we think  
will be most common in our user base. That said, thanks to the things  
you pointed out, I'm beginning to think that our users might be such a  
varied group that precompiled binaries might not be worth the trouble.

Ned, I'm on Mac and I was under the impression that the deployment  
target compiler option would control how the resulting binary (in this  
case, Python) called OS X but it wouldn't have any affect on how other  
code (like our library) called Python. Is that not the case?


Thanks
Philip