Last Update: 23.05.2017. By Jens in python | pyside
I build several desktop applications using PySide. It works like a charm on Windows. However, I found a nasty bug in the Mac version which I could not reproduce on my local machine. This one drove me nuts. It was hard to analyze, I own just one Mac and do not have access to another machine. Luckily, with the help of some very long googling (guessing symptoms) and the help of a user of one of my applications, I could fix the issue. As a reminder for myself and help for you, I document it.
I build the application using PySide, Py2App and Python 3 on a Mac using a virtualenv. I used Brew for installing PySide and Python, and PySide was also installed inside my virutaenv.
The application builds and runs fine on my machine.
However, on a different Mac, the application crashed without any useful traces in the system logs.
My application also writes a separate log file, but this was empty. So it seemed like the application crashed before even reaching my code.
After some google and adjusting my log outputs, however, I found out that it started to execute my code and then crashed when initializing PySide.
First, I thought it was just a problem on this single users machine, but I got a similar bug report which gave me some hints it might be a general problem.
Now, better equipped I found the culprit after some additional googling.
The application could not load the QT binaries.
The problem is a combination of installing PySide and with Brew and using PySide inside a virtualenv. While building the application Py2App can’t pick up the correct library path, and the generated application includes the libraries but with an incorrect path in the Mac specific descriptors.
otool -L <my-app>/Contents/Resources/lib/python3.4/lib-dynload/PySide/QtGui.so
It should list the file with @executable_path and not with an absolute path only valid for your machine.
In my case, the binaries were referenced by absolute paths which were of course not valid on someone else machine.
I do not know who exactly is causing this issue, but the following workaround did help me.
And then continue building the application as before. This time the lib references were fine in the application.
Guess what?
It worked now. Yippie.