On 2010-08-12, at 5:54 PM, Ned Deily wrote:
> In article <84cb970d-35a3-45ea-9b5c-5a1da09dd...@activestate.com>,
> Sridhar Ratnakumar <sridh...@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.
Thanks for the explanation.
However, I see all three variants (32, 64, and 2-way) in the default 2.6.6c1
install (i.e., internal ActivePython build, though this is likely the case for
the python.org's 10.5 installer as well):
-rwxr-xr-x 1 root admin 12644 10 Aug 15:30
/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-32
-rwxr-xr-x 1 root admin 12680 10 Aug 15:30
/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-64
-rwxr-xr-x 1 root admin 24968 10 Aug 15:30
/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-all
But bin/python2.6 itself links to python2.6-32. What about changing that to
python2.6-all - thus leaving the choice of arch to OS loader instead of the
Python's build system?
Effectively, this change would likely come down to this patch:
sridh...@whymac:~/code/o/py/release26-maint/Mac > dif
Index: Makefile.in
===================================================================
--- Makefile.in (revision 83986)
+++ Makefile.in (working copy)
@@ -83,10 +83,10 @@
ln -sf python$(VERSION)-all "$(DESTDIR)$(prefix)/bin/python-all"
ln -sf pythonw$(VERSION)-all "$(DESTDIR)$(prefix)/bin/pythonw-all"
- ln -sf pythonw$(VERSION)-32
"$(DESTDIR)$(prefix)/bin/pythonw$(VERSION)"
- ln -sf python$(VERSION)-32
"$(DESTDIR)$(prefix)/bin/python$(VERSION)"
- ln -sf pythonw$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/pythonw"
- ln -sf python$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/python"
+ ln -sf pythonw$(VERSION)-all
"$(DESTDIR)$(prefix)/bin/pythonw$(VERSION)"
+ ln -sf python$(VERSION)-all
"$(DESTDIR)$(prefix)/bin/python$(VERSION)"
+ ln -sf pythonw$(VERSION)-all "$(DESTDIR)$(prefix)/bin/pythonw"
+ ln -sf python$(VERSION)-all "$(DESTDIR)$(prefix)/bin/python"
#
# Install unix tools in /usr/local/bin. These are just aliases for the
Is this something that can become part of 2.6.6 final?
-srid
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
