[Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?

[Ned Deily]

In article <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD at activestate.com>,
 Sridhar Ratnakumar <sridharr at activestate.com> wrote:

> When Python 2.6 is built with --universal-archs=intel, the default Python 
> binary is symlinked to the 32-bit binary:
> 
>   lrwxr-xr-x  1 root  admin     12 10 Aug 15:31 python -> python2.6-32
> 
> Python 2.7, however, is 64-bit by default. Is there a particular reason why 
> this behaviour is different for 2.6 (and 3.1)?

For 2.7 and (upcoming) 3.2, code was added to allow dynamic selection of 
arch of a universal Python build, like so:

   arch -i386 /usr/local/bin/python2.7
   arch -x86_64 /usr/local/bin/python2.7

Without the use of arch, OS X defaults to an appropriate default, on 
10.6 preferring x86_64 if available.

On earlier versions like 2.6 and 3.1, the "arch" trick does not work 
because an execv(2) was used in the "wrapper" program 
(Mac/Tools/pythonw.c) to run the real interpreter and that causes the 
interpreter to run in the OS's preferred arch.  The new releases 
modified pythonw.c to use posix_spawnv(2) to ensure the interpreter is 
started using the same CPU arch as the wrapper program is running in.  
(The Apple-supplied /usr/bin/python in 10.6 takes a somewhat different 
approach to the problem.)

n the earlier versions (2.6/3.1 and earlier), the solution for universal 
variants with 32-/64-bit archs was to install separate 32-bit-only and 
64-bit-only interpreter executable files and install separate wrapper 
programs for each (python2.6-32 and python2.6-64) with the default names 
(python2.6/python) always symlinked to the 32-bit version.

It would be possible to backport the 2.7/3.2 solution to 2.6 but, as it 
affects both pythonw.c and various parts of the configure and make 
files, it's not likely to be done, certainly not for the imminent 2.6.6 
release.

-- 
 Ned Deily,
 nad at acm.org