[Pythonmac-SIG] What to build binaries for???

[Ned Deily]

In article <4B43D659.4090709 at noaa.gov>,
 Christopher Barker <Chris.Barker at noaa.gov> wrote:
> Another poster on the numpy list has been bitten by the "must have the 
> system python" issue with the binary installer, meaning the python.org 
> build.
> 
> 1) I thought I provided a patch a good while ago to update that message 
> -- did that get lost in the shuffle?

Sorry, could you refresh my memory what that issue is?
 
> 2) we're talking on that list about implementing what Robin Dunn has 
> done for wxPython -- a single installer that puts numpy somewhere, then 
> puts *.pth files in both the Apple and Python.org Pythons, so that a 
> single installer will work with both.

Without knowing the details, that could be a dicey proposition if there 
are any C extensions involved.   There is no guarantee that a single set 
of binaries would work on multiple instances of python, even the same 
source level, if the pythons themselves were not built with the same 
options and tool chains.  At the moment, that certainly is not true for 
the Apple and the python.org pythons in  any of 10.4, 10.5, and 
especially 10.6.

> But now we have issues as to what to support: 32+64 bit, PPC + intel. 
> wxPython is strictly 32 bit, so it's a bit easier.
> 
> What is being delivered now? Is there a 64 bit build at Python.org? What 
> has Apple delivered with 10.6 and 10.5?

At the moment, python.org's most recent installers are for 2.6.4 and 
3.1.1.  Both are 32-bit-only i386/ppc and are built with GCC 4.0.1 and 
the 10.4u SDK using a deployment target of 10.3; they should work 
correctly on 10.4, 10.5, and 10.6.  AFAIK, neither received any 
pre-release testing on 10.3.9 (the only version of 10.3 that could 
work), although there was a recent report here of a minor installation 
problem with 2.6.4 on 10.3.9   (http://bugs.python.org/issue7437).

There are a couple of issues with building C extension modules on 10.6 
that were fixed in 2.6.4 which was released after 10.6 but not in 3.1.1 
which was before 10.6.  The two major ones: you need to ensure that the 
10.4u SDK is installed from the 10.6 Xcode mpkg (by default, it's not) 
and you need to tell Distutils to use gcc-4.0 instead of the 10.6 
default gcc-4.2: 

$ export CC=/usr/bin/gcc-4.0

Again, these problems are fixed in 2.6.4.

In 10.6, Apple supplies a Python 2.6.1 (3-way build with 64-bit Intel as 
default) and a Python 2.5.4 (2-way 32-bit only) both built with GCC 
4.2.1.  2.6.1 has a deployment target of 10.6 while 2.5.4's is 10.5:

$ cd /System/Library/Frameworks/Python.framework/Versions/2.6/bin
$ file python2.6
python2.6: Mach-O universal binary with 3 architectures
python2.6 (for architecture x86_64):   Mach-O 64-bit executable x86_64
python2.6 (for architecture i386):  Mach-O executable i386
python2.6 (for architecture ppc7400):  Mach-O executable ppc
$ cd ../2.5/bin
$ file python2.5
python2.5: Mach-O universal binary with 2 architectures
python2.5 (for architecture i386):  Mach-O executable i386
python2.5 (for architecture ppc7400):  Mach-O executable ppc

In 10.5.8, the Apple-supplied Python is 2.5.1 (2-way 32-bit) built with 
GCC 4.0.1 and a 10.5 deployment target.

> Are we going to need multiple installers, maybe 32 and 64 bit?

Dunno.   Again, as it stands at the moment, there are no python.org 
64-bit installers although some work is in progress.  Ronald has 
recently checked-in some feature code for 2.7 to make 64-bit/32-bit 
selection work on 10.6 (the 10.5 4-way build support doesn't work 
correctly on 10.6 and legacy ppc64 support is largely gone in 10.6 
anyway).  I'm hopeful we can get that all working and pushed back into 
future 2.6 and 3.1 maintenance releases, assuming the need for them 
arises.  That will probably result in two separate installers for each 
python version: one 32-bit only built as in the past for 10.3.9+ and a 
new 2-way (Intel-only 32/64, 10.6 or higher) or 3-way (2-way plus ppc, 
10.5 or higher).

That's my (unofficial) impression of the State of the World.  Perhaps 
Ronald has other suggestions/comments/ideas?

-- 
 Ned Deily,
 nad at acm.org