Prev: What does the output of return os.lstat(logFile)[ST_CTIME] mean?
Next: python terminology on classes
From: Philip Semanchuk on 27 Jul 2010 17:44

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

> In article <i2kok1$krp$1(a)dough.gmane.org>,
> Christian Heimes <lists(a)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









First  |  Prev  | 
Pages: 1 2
Prev: What does the output of return os.lstat(logFile)[ST_CTIME] mean?
Next: python terminology on classes