Mac OS X build environment

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Mac OS X build environment

jamesw
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X build environment

Chris Barker - NOAA Federal
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 <[hidden email]> 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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X build environment

Robin Dunn
In reply to this post by jamesw
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
http://wxPython.org

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X build environment

jamesw
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

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X build environment

jamesw
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.

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

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

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X build environment

jamesw
Hi,

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

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


--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X build environment

jamesw
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

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.