In article <2d5132a50910251527r616311b7tac4de0e04b241...@mail.gmail.com>, Robin <robi...@gmail.com> wrote: > On Sun, Oct 25, 2009 at 10:15 PM, William Kyngesburye > <wokl...@kyngchaos.com> wrote: > > Something I noticed with the Apple Python is that /usr/bin/python (which is > > it's own binary and not a symlink) *only* responds to the env variable > > VERSIONER_PYTHON_PREFER_32_BIT (I think that's the name). While > > /usr/bin/python2.6 (which is a symlink to the executable in the framework) > > *only* responds to the arch command. [...] > I tried but I can't get the environment variable to have any effect on > the self-built python.org version.
That environment variable is something added by Apple to the Python they supply with OS X 10.6. As you've discovered, it is not part of the official python.org distribution. In article <2d5132a50910260847j49c06566i6096eb6e3118f...@mail.gmail.com>, Robin <robi...@gmail.com> wrote: > On Mon, Oct 26, 2009 at 3:17 PM, David Warde-Farley > <d...@cs.toronto.edu>wrote: > > Check if there's a > > /Library/Frameworks/Python.framework/Versions/2.6/bin/python-64 (or > > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-64). IIRC > > that's how the builds produced from source work; separate executables for 32 > > and 64 bit mode. > > > > Hi, > > Thanks... yes thats what I was expecting initially, but there is nothing > there: > jm-g26b101:bin robince$ ls > /Library/Frameworks/Python.framework/Versions/2.6/bin/ > 2to3 pydoc python-config pythonw > smtpd2.6.py > idle pydoc2.6 python2.6 pythonw2.6 > idle2.6 python python2.6-config smtpd.py > > >From reading the documentation I think they may only be created with the > universal-archs=all target (which includes ppc and ppc64 which I dont need). That is correct. However, even if you did build with "all" (i.e. a 4-way universal build), that would still not solve your problem on 10.6. See below. > In any case - 'file' shows that it is a universal binary, just the 'arch' > method of selecting architecture doesn't appear to work: > jm-g26b101:bin robince$ file > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6: Mach-O > universal binary with 2 architectures > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for > architecture i386): Mach-O executable i386 > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for > architecture x86_64): Mach-O 64-bit executable x86_64 The problem here is that that "python2.6" binary in the framework bin directory is not the interpreter itself, rather it is a launcher that execv's to the real interpreter binary located in an app bundle within the framework. This is also true of all of the other variants you may see in bin: pythonw, python32, etc. So starting any of those executables with "arch -i386" only forces the launcher process to run in 32-bit, the interpreter is then still execv-ed as 64-bit if available. The reason for the indirection is explained here: http://bugs.python.org/issue6834 Basically it is to allow certain GUI functions to work correctly when python is invoked from the command line. I've updated the issue to include some workarounds until the problem is fixed; you might also want to try Ronald's patch. -- Ned Deily, n...@acm.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
