2

On OSX, I have a Python universal binary which just contains 32-bit code:

$ file $(python3.2-32)
/Library/Frameworks/Python.framework/Versions/3.2/bin/python3.2-32: Mach-O universal binary with 1 architecture
/Library/Frameworks/Python.framework/Versions/3.2/bin/python3.2-32 (for architecture i386): Mach-O executable i386

I create a virtualenv using this binary:

$ virtualenv -p python3.2-32 myenv
Running virtualenv with interpreter /Library/Frameworks/Python.framework/Versions/3.2/bin/python3.2-32
New python executable in myenv/bin/python
Please make sure you remove any previous custom paths from your /Users/jhartley/.pydistutils.cfg file.
Installing distribute........................................................................................................................................................................done.
Installing pip...............done.

But the virtualenv contains a binary with both 32 and 64 bit code:

$ . myenv/bin/activate
(myenv)$ file $(which python)
/Users/jhartley/myenv/bin/python: Mach-O universal binary with 2 architectures
/Users/jhartley/myenv/bin/python (for architecture i386):   Mach-O executable i386
/Users/jhartley/myenv/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64

I need to use a Python binary which contains just 32 bit code, not 64 bit.

I don't mind it being a universal binary, just so long as it runs in 32 bit mode by default, without me having to invoke it using 'arch -i386', since I'm not in control of how this application gets launched.

Jonathan Hartley
  • 15,462
  • 9
  • 79
  • 80

1 Answers1

3

I'm not exactly sure why this behavior is happening, but I can offer a workaround. You could just strip the virtualenv's python down to i386 one time. Then it would no longer require an environment flag to ensure 32-bit:

source bin/activate
file `which python`
# .../bin/python: Mach-O universal binary with 2 architectures
# .../bin/python (for architecture i386):   Mach-O executable i386
# .../bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64
lipo -thin i386 `which python` -output `which python`
file `which python`
# .../bin/python: Mach-O executable i386
jdi
  • 90,542
  • 19
  • 167
  • 203
  • 3
    The reason it is happening is that, for OS X framework builds, `virtualenv` copies the actual Python executable (located within the Python.app bundle in the framework) rather than the stub launcher binary (in this case, the thinned-down i386-only launcher) from the framework `bin` directory. The virtual environment feature, `venv` being added to the standard library in Python 3.3 gets this right: `python3.3-32 -m venv myenv` – Ned Deily Jun 11 '12 at 03:50
  • @NedDeily: Thanks for the info! Thats definitely a solid explanation. – jdi Jun 11 '12 at 04:55
  • Thanks for the fix, which works as described, and thanks to @Ned for the insight. – Jonathan Hartley Jun 12 '12 at 13:06