Mac OS X build environment

wxPython Users
1

Hi,

I started a wxPython project just over a year ago, and at the time, when setting up my Mac OS X “build environment” (*), I chose to use the Universal Binary build of Python 2.7.3 from Python.Org, and I found a corresponding build of wxPython (wxPython2.8-osx-unicode-2.8.12.1-universal-py2.7), which worked well with it.

(*) When I say “build environment”, I mean an environment where I can install Python modules from source, and I can build a frozen Python application with PyInstaller or Py2App.

I ran into a slight complication when I was trying to install Python modules which required compiling C code. The Python binary I had downloaded was built with gcc 4.0, but my Xcode developer tools had provided gcc 4.2, so I had to jump through a few hoops to install an old version of the Xcode developer tools to get an appropriate version of gcc (4.0) for building Python modules from source.

Now I’m getting other developers to help with the Mac builds of the application, and they have asked whether it would be better to use the official version of gcc in the latest Xcode Developer tools and build Python and wxPython from source. Installing the old version of Xcode (with gcc 4.0) has been particularly painful recently, because it can cause a kernel panic in OS X 10.8 (http://stackoverflow.com/questions/12081784/com-apple-iokit-chudkernlib-kernel-panic-fix).

I haven’t tested the latest Python 2.7.x binary from Python.Org to see if it’s still built with gcc 4.0.

Are there any recommendations from other wxPython developers using Mac OS X ?

Thanks,
James

2

This may be a better question for the pythonmac list, but…

Robin, most wonderfully, provides binaries for the builds on python.org.

Those builds attempt to support backward compatability as much as possible, and if you want to use py2app, etc. you probably want that too.

Apple is not so good with the backward- compatibility–it’s tricky to build for older systems on newer systems…

Anyway: there are two builds on python.org. The 32 bit ppc+ intel and the 32+64 bit intel only. The latter is built with newer SDKs and, I think, a newer compiler.

If you are already using that, then darn.

You may be able to jump to a newer compiler, as long as you use the 10.6 SDKs – not sure, I’m still on 10.7, partly for this reason!

Otherwise, you’ll need to build the whole stack yourselves, and won’t be supporting older systems. ( maybe you don’t need to)

HTH,

Chris

···

On Aug 21, 2013, at 10:22 PM, James W james.wettenhall@monash.edu wrote:

Hi,

I started a wxPython project just over a year ago, and at the time, when setting up my Mac OS X “build environment” (*), I chose to use the Universal Binary build of Python 2.7.3 from Python.Org, and I found a corresponding build of wxPython (wxPython2.8-osx-unicode-2.8.12.1-universal-py2.7), which worked well with it.

(*) When I say “build environment”, I mean an environment where I can install Python modules from source, and I can build a frozen Python application with PyInstaller or Py2App.

I ran into a slight complication when I was trying to install Python modules which required compiling C code. The Python binary I had downloaded was built with gcc 4.0, but my Xcode developer tools had provided gcc 4.2, so I had to jump through a few hoops to install an old version of the Xcode developer tools to get an appropriate version of gcc (4.0) for building Python modules from source.

Now I’m getting other developers to help with the Mac builds of the application, and they have asked whether it would be better to use the official version of gcc in the latest Xcode Developer tools and build Python and wxPython from source. Installing the old version of Xcode (with gcc 4.0) has been particularly painful recently, because it can cause a kernel panic in OS X 10.8 (http://stackoverflow.com/questions/12081784/com-apple-iokit-chudkernlib-kernel-panic-fix).

I haven’t tested the latest Python 2.7.x binary from Python.Org to see if it’s still built with gcc 4.0.

Are there any recommendations from other wxPython developers using Mac OS X ?

Thanks,

James

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

3

James W wrote:

I haven't tested the latest Python 2.7.x binary from Python.Org to see
if it's still built with gcc 4.0.

Are there any recommendations from other wxPython developers using Mac
OS X ?

As Chris mentioned, use the 64-bit compatible build from Python.org. It's built with gcc 4.2 and works fine when building extensions with new Xcode versions on 10.7 and 10.8. If you want to support deploying on 10.6 then I think you'll need to stay on 10.7 as the current Xcode for 10.8 does not include the 10.6 SDK. There are stories of it working if you copy the SDK from an older Xcode, but it didn't work very well for me when I tried it.

···

--
Robin Dunn
Software Craftsman

4

Chris and Robin,

Thanks very much for your quick replies!

Following your advice, we'll try the 64-bit compatible Python 2.7 build from Python.org on our OS X 10.8 build machine with the latest Xcode.

Thanks for alerting us to the potential difficulty with deploying to OS X 10.6 from OS X 10.8. I would guess that we don't have any users still running OS X 10.6, but we should probably check, just in case...

Robin, thanks for all of your incredible efforts in developing and supporting wxPython - I must have read hundreds of your posts in the wxPython-users archives!

Cheers,
James

5

Hi,

Sorry for the late follow-up, but I thought I should post back to this thread with one potential gotcha, in case anyone else tries to follow the advice in this thread.

As Chris mentioned, use the 64-bit compatible build from Python.org. It’s built with gcc 4.2 and works fine when building extensions with new Xcode versions on 10.7 and 10.8. If you want to support deploying on 10.6 then I think you’ll need to stay on 10.7 as the current Xcode for 10.8 does not include the 10.6 SDK. There are stories of it working if you copy the SDK from an older Xcode, but it didn’t work very well for me when I tried it.

For anyone else trying the 64-bit compatible Python build from Python.org in combination with the stable (2.8) version of wxPython, please don’t get put off by this error:

>>> ``import wx

Traceback (most recent call last):

``File ``"<stdin>"``, line ``1``, in <module>

``File ``"/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/__init__.py"``, line ``45``, in <module>

``from wx._core ``import *

``File ``"/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core.py"``, line ``4``, in <module>

``import _core_

ImportError: dlopen(/usr/local/lib/wxPython-unicode-``2.8``.``12.1``/lib/python2.``7``/site-packages/wx-``2.8``-mac-unicode/wx/_core_.so, ``2``): no suitable image found. Did find:

``/usr/local/lib/wxPython-unicode-``2.8``.``12.1``/lib/python2.``7``/site-packages/wx-``2.8``-mac-unicode/wx/_core_.so: no matching architecture in universal wrapper

>>>

It just means that you are running Python in 64-bit mode, so you can’t import the 32-bit wxWidgets shared library from wxPython 2.8.

An easy workaround is to run “python-32” instead of “python”, and if you are happy with always running Python in 32-bit mode, you can set:

alias python=“python-32”

in your ~/.bash_profile

If you bundle your app with py2app or similar, then the end-user never needs to know that you had to use a trick like “python-32” to build your application.

You can check your architecture as follows:

$ python-32

>>> ``import struct

>>> struct.calcsize(``"P"``) * ``8

32

>>> # so we must be running in ``32``-bit mode!

>>>

>>> ``import sys

>>> running_in_32_bit_mode = (sys.maxsize <= ``2``**``32``)

>>> running_in_32_bit_mode

True

>>> # again confirming that we are running in ``32``-bit mode!

>>>

>>> # But what about the following method?

>>>

>>> ``import platform

>>> platform.architecture()

(``'64bit'``, ``''``)

>>> # OK, so ``this final method can't be trusted.

Cheers,

James

···

On 24/08/2013, at 11:12 AM, Robin Dunn wrote:

6

Hi,

ImportError: dlopen(/usr/local/lib/wxPython-unicode-``2.8``.``12.1``/lib/python2.``7``/site-packages/wx-``2.8``-mac-unicode/wx/_core_.so, ``2``): no suitable image found. Did find:

``/usr/local/lib/wxPython-unicode-``2.8``.``12.1``/lib/python2.``7``/site-packages/wx-``2.8``-mac-unicode/wx/_core_.so: no matching architecture in universal wrapper

>>>

It just means that you are running Python in 64-bit mode, so you can’t import the 32-bit wxWidgets shared library from wxPython 2.8.

An easy workaround is to run “python-32” instead of “python”, and if you are happy with always running Python in 32-bit mode, you can set:

alias python=“python-32”

But this doesn’t necessarily work for py2app. (I haven’t tried PyInstaller on Mac OS X yet…)

In my py2app output, (even after trying to specify an architecture of “i386”), I see the following:

copying /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python → /path/to/my/wxpython/code/dist/MyApp.app/Contents/MacOS/python

copying /Library/Frameworks/Python.framework/Versions/2.7/Python → /path/to/my/wxpython/code/dist/MyApp.app/Contents/Frameworks/Python.framework/Versions/2.7

where in each case, “Python” is a fat binary:

$ file Python

Python: Mach-O universal binary with 2 architectures

Python (for architecture i386): Mach-O dynamically linked shared library i386

Python (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

The only way I could figure out how to prevent py2app from using a 64-bit-capable Python binary was to strip the 64-bit architecture from the two Python binaries referenced above, using Mac OS X’s “lipo” command, i.e.

cd /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/

sudo cp Python Python.orig

sudo lipo -remove x86_64 Python -output Python

cd /Library/Frameworks/Python.framework/Versions/2.7/

sudo cp Python Python.orig

sudo lipo -remove x86_64 Python -output Python

Then after doing that, the Python binary bundled by py2app runs in 32-bit mode, as needed for the stable (v2.8) wxPython version on Mac OS X.

Of course, py2app may still copy other fat binaries into my application bundle, e.g. shared libraries from:

/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/

They too can be stripped of their 64-bit architecture, using “lipo”, but this is starting to get very off topic for a wxPython list post.

Cheers,

James

···

On 09/09/2013, at 7:17 PM, James Wettenhall wrote:

7

Hi,

My latest strategy is to install a 32-bit-only Python 2.7.x from source, which seems to be working well with wxPython and with py2app.

To recap,

  • the 32-bit/PPC Python 2.7.x from Python.Org works with the stable (2.8) wxPython on Mac OS X, but this Python is built with gcc 4.0, so it doesn’t play well with the latest Xcode (with gcc 4.2) when installing Python modules which require compiling C code.

  • the 64-bit/32-bit Python 2.7.x from Python.Org is built with gcc 4.2, so it plays well with the latest Xcode, but you have to explicitly run it in 32-bit mode to import wx, and this gets tricky when py2app tries to copy fat Python binaries (64-bit/32-bit) into your application bundle directory.

I started looking at how to remove the 64-bit architecture from the 64-bit/32-bit Python binaries, but that became rather messy…

So installing 32-bit-only Python from source seems like a reasonable approach:

tar zxvf Python-2.7.5.tgz

cd Python-2.7.5/

CFLAGS=-m32 LDFLAGS=-m32 ./configure --enable-shared

make

sudo make install

export PYTHONPATH=/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/:$PYTHONPATH

/usr/local/bin/python

import wx

And it seems to work with py2app. Even though I’m now using a 32-bit-only Python binary, I think it’s still a good idea to explicitly pass arch=“i386” to py2app, to make sure that I don’t get a 64-bit binary for MyApp.app/Contents/MacOS/MyApp

Cheers,

James