It Shouldn’t Hurt This Much

  1. One of my students says good things about Spyder, a Python environment with MATLAB-like features. OK, I’d like to give it a try.
  2. On Mac OS X.
  3. Ah—it need PyQT.
  4. And SIP.
  5. And some optional modules, but I’ll ignore those for now.
  6. So the first step is to install Qt.
  7. But there aren’t binaries—I have to do that from source.
  8. So I have to get XCode onto this machine (fine, that works, it just takes 30 minutes to download).
  9. And hey, Qt builds—I’m on a roll.
  10. So, go into the PyQT directory, do “python configure.py” to, um, configure it, then run “make”.
  11. Good, good, good, then: kaboom. The error message is:
g++ -c -pipe -fPIC -O2 -Wall -W -DNDEBUG -DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I/Users/gregwilson/PyQt-mac-gpl-4.7.6/qpy/QtCore -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/mkspecs/macx-g++ -I/Library/Frameworks/QtCore.framework/Headers -I/usr/include -F/Users/gregwilson/PyQt-mac-gpl-4.7.6/qpy/QtCore -F/Library/Frameworks -o sipQtCorecmodule.o sipQtCorecmodule.cpp
In file included from /Library/Frameworks/QtCore.framework/Headers/qmetatype.h:45,
from /Library/Frameworks/QtCore.framework/Headers/QMetaType:1,
from sipAPIQtCore.h:40,
from sipQtCorecmodule.cpp:34:
/Library/Frameworks/QtCore.framework/Headers/qglobal.h:288:2: error: #error "You are building a 64-bit application, but using a 32-bit version of Qt. Check your build configuration."
make[1]: *** [sipQtCorecmodule.o] Error 1
make: *** [all] Error 2

Er, what? Why does it think I’m trying to build a 64-bit application? Earlier compile lines say:

g++ -c -pipe -fno-strict-aliasing -O2 -arch i386 -fPIC -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Qt4.6/mkspecs/macx-g++ -I. -I/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/usr/include/QtCore -I/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/usr/include/QtGui -I/usr/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I../../QtCore -I. -I. -F/Library/Frameworks -o moc_qpycore_pyqtproxy.o moc_qpycore_pyqtproxy.cpp

I’ve highlighted the “-arch i386″ line to show that yes, Qt knows I’m on a 32-bit processor—at least, when it’s compiling the files in libqpycore.a. Is it a bug in the SIP build and install? Is it—aw, do I really care? Spyder looks nice, but increasingly, my feeling is that if an application doesn’t “just install”, I’m not interested: I certainly can’t ask students doing Software Carpentry to wrestle with issues like this.

*sigh*

Later: this page helped, but not enough: I’ve got PyQT 4.7.6 installed (at least, “make / make install” in PyQt-mac-gpl-4.7.6 ran to completion), and “python setup.py install” in the spyder-1.1.5 directory worked, but when I try to run spyder from the command line (/usr/local/bin/spyder), it tells me that it can’t find PyQT version 4.4. Don’t think I’m going to be introducing my students to it any time soon…

8 thoughts on “It Shouldn’t Hurt This Much

  1. Pat

    Lesson #1 for every geek with a Mac: Install the XCode developer tools and then install MacPorts. While you still would have had to compile all the code, MacPorts would have done it all for you with a single command: ‘sudo port install py26-spyder’. That’s all the dependencies, downloads, configures, builds and installs. Even if Spyder hadn’t been available, you can install PyQt version 4 for Python versions 2.5, 2.6. 2.7 and 3.1. MacPorts even makes it easy to have them all installed at the same time (use the python_select and gcc_select packages).

  2. Victor Ng

    This is a guess, but is it OSX’s python? It’s probably 64-b options are probably getting passed through via python-config or something like that.

    Something else is probably not that smart and is using the (incorrect) 32-bit architecture.

    Fun!

    I gave up on anything requiring gcc for OSX.

    Let the Linux nerds sort out compiler flags for me. I’m asian – figuring out this stuff doesn’t put any hair on my chest and if I had any hair on my head, it makes me want to pull it all out.

    In the bizarro land of 2010, Linux is more user friendly when the user is a programmer.

  3. Rob Britton

    In Linux (read: Ubuntu) it’s easy:
    1) Open Synaptic (or whatever package manager your distro has, if you’re using a distro without a decent package manager then installing things from source should be second nature to you anyway)
    2) Search for pyqt and sip
    3) Install the Python packages it finds – for me it is python-qt4-dev and python-sip
    4) Install Spyder (this might be the hard part, maybe involving some command line stuff)

    Doesn’t Mac OS X have some sort of package management system? Seems like you’re trying to do this the hard way (aka compiling everything from source).

  4. Cameron Neylon

    Yep, I had this problem. I think if I recall correctly you’ve got to build both QT and pyQT explicitly as the 64 bit version. Of course, I didn’t take notes at the time on what was required [mea culpa] but it did take me a whole weekend to get it working. A trick I haven’t tried which might work is to download mantid (mandtidproject.org) which is supposed to include a functional PyQT environment but only again Python 2.4 I think.

    That said I’ve been able to do a lot of good stuff with PyQt once I got it up and working. So it has been worthwhile for me. Wouldn’t recommend imposing it on students tho…

  5. Konrad Hinsen

    Short-term comment: the best bet for getting Qt and PyQt on a Mac today is MacPorts. It still requires installing Xcode and then MacPorts, but then a single command (port install py26-pyqt4) will launch the full installation of everything required, including Python itself. It takes close to forever, but you can lean back and watch your computer work.

    Long-term comment: Lots of modern software, in particular GUI-based stuff, is much too complicated to install. But I see this from both sides, developers’ and users’, and it seems that there is no way around this for either one. Open Source developers rarely have the resources to package binary releases of their code for all popular platforms at every release, and insufficient influence on the packages they depend on to facilitate installation on the users’s side.

    For me this is one of the most urgent problems to solve, but I am not very optimistic. Ultimately the problem is not a technical one, but a social one, as we need more standardization in computing platforms if we want to make thorough testing of installation procedures a realistic prospect. Unfortunately standardization is not in the interest of platform vendors today, so it won’t happen. The best evidence is the Linux world: different distributions become more and more different in lots of details, making the packager’s life ever more difficult.

  6. Greg Wilson Post author

    @all Ports “solved” my problem (2.5 hours and several gigabytes of downloads and builds later). Still too much to ask of neophytes…

    @Rob and others: as Konrad observes, divergence in Linux distros is making packaging harder every year. As a friend once said, Windows may be broken, but at least it’s broken the same way everywhere… *sigh*

  7. Derek

    “Windows may be broken, but at least it’s broken the same way everywhere…”
    I have to insert an annoying and overused acronymn here – LOL.
    I was recently on a course learning QGIS (Quantum GIS). This software “just worked” on the Linux (read: Ubuntu) machines; it both worked and failed on the variety of Windows machines – in some cases both working and failing on the same version of Windows with the same SP. This correlates with my previous 15 years of experience writing software for Windows – development is fun but installation is hell! I’ve been *very* impressed with my few years of experience on Ubuntu.

  8. Randy

    Hooray for mac ports!!! After almost two weeks of beating my head on this in my spare time, I actually googled “spyder is too hard to install matlab”, not because I thought I would find an easier way to install, but because I thought I would see if anybody was making it easier and was considering how I could help. It never occurred to me that there is an “easy” way that is not documented on the spyder webpage. The comments on this blog saved my Saturday! Thanks!!!
    (Actually first I searched without matlab, but that gave me random stuff because google apparently thinks “spyder” and “spider” are interchangeable – I wish there were some way to tell the search engine that I can spell.)

Comments are closed.