This application failed to start because it could not find or load the Qt platform plugin "cocoa"
When building an app with cx_Freeze on MacOSX all dependent libraries (.so files on MacOSX) are packaged into the application bundle. It is this that makes the application portable to other systems, without requiring a second install of Qt.
When launching the Application, the libraries should therefore be loaded from within the bundle. However, in your case the system libraries are still being loaded:
/Users/.../build/coublet-0.5.70.app/Contents/MacOS/QtWidgets/usr/local/Cellar/qt5/5.3.1/lib/QtWidgets.framework/Versions/5/QtWidgetsThe result One of the two will be used. Which one is undefined. means that either of these could be loaded. If it picks the correct one, great! If it doesn't you've got two separate sets of libraries loading simultaneously, and that fails shortly afterwards. As an aside, you may find that if you try your Application on another system it will work fine! Sometimes.
For an overview of the problem I suggest taking a look at the following bug #33.
Before you begin
Make sure you have an up-to-date version of cx_Freeze installed. I would suggest trying to clone the repository and installing from there.
Secondly, ensure that the Qt plugins are being correctly built into your application. Cx_Freeze previously looked for the qt-menu.nib file to determine if it was building a Qt application. This is no longer available in Qt5, but you can pass it on the command-line when building your app. Set it to whatever you want, it really doesn't matter:
python setup.py bdist_mac --qt-menu-nib=/usr/local/Cellar/qt5/5.3.1/plugins/platforms/This may be enough to fix your problem. But if not, you have two options:
Option 1
Each library file contains the paths to it's dependencies. If you're receiving this error, it means some of those paths are either a) still pointing to the original file, or b) not specific enough (and being found on your PATH or DYLD_LIBRARY_PATH). However, you can re-write paths using install_name_tool from the command line (as described here:
install_name_tool -change /usr/local/Cellar/qt5/5.3.1/lib/QtWidgets.framework/Versions/5/QtWidgets @executable_path/QtWidgets build/MyApp.app/Contents/MacOS/qt_plugins/platforms/libqcocoa.dylibinstall_name_tool -change /usr/local/Cellar/qt5/5.3.1/lib/QtCore.framework/Versions/5/QtCore @executable_path/QtCore build/MyApp.app/Contents/MacOS/qt_plugins/platforms/libqcocoa.dylibinstall_name_tool -change /usr/local/Cellar/qt5/5.3.1/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport @executable_path/QtPrintSupport build/MyApp.app/Contents/MacOS/qt_plugins/platforms/libqcocoa.dylibinstall_name_tool -change /usr/local/Cellar/qt5/5.3.1/lib/QtGui.framework/Versions/5/QtGui @executable_path/QtGui build/MyApp.app/Contents/MacOS/qt_plugins/platforms/libqcocoa.dylibThis rewrites the paths in the libraries to point into your application folder, using @executable_path as the base. You will need to do this for all the paths that you find loading incorrectly. I'd suggest wrapping it up into an script, to run automatically after the build.
If you want to look at which libraries a file is referencing you can use otool. For example, in a successfully built application of mine:
otool -L libqcocoa.dylib libqcocoa.dylib: @executable_path/../Resources/qt_plugins/platforms/libqcocoa.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0) ...There was an updated workaround in the issue tracker that suggests that just importing the correct module in your app will get it to function, however it seems unlikely that you've made an application without QtWidgets.
Option 2
If the above doesn't work, there is another approach outlined here. This is a bit of a sledgehammer approach in that it simply prevents loading of plugins at all.
Add a
qt.conffile next to the executable (in the.appbundle that contains:[Paths]Plugins = '.'Either set the environment variable
QT_PLUGIN_PATH=""(you can do this within your application before importingPyQt. Or callQtGui.QApplication.setLibraryPaths([])before creating your application object.
The result is no plugins, so your application will not have access to the MacOSX Cocoa style and UI (e.g. file, colour dialogs).
Use this command :
pip install opencv-python-headlessIt resolved the same issue in my case.
This is in addition to @mfitzp's answer.
This QT Plugins Document came in handy.
To look for default locations that your QT app is trying to search you can use following command:
$sudo dtruss MacOS/ncher getattrlist("/ncher.app\0", 0x7FFF954B51A4, 0x7FFF5C8FDD20) = 0 0 getattrlist("/ncher.app/Contents\0", 0x7FFF954B51A4, 0x7FFF5C8FDD20) = 0 0 getattrlist("/ncher.app/Contents/MacOS\0", 0x7FFF954B51A4, 0x7FFF5C8FDD20) = 0 0 stat64("/ncher.app/Contents/MacOS\0", 0x7FFF5C8FDED8, 0x7FFF5C8FDD20) = 0 0 stat64("/ncher.app/Contents/MacOS/platforms/.\0", 0x7FFF5C8FDF58, 0x7FFF5C8FDD20) = -1 Err#2 open("/dev/tty\0", 0x1000000, 0x1FF) = 5 0 fcntl(0x5, 0x2, 0x1) = 0 0 close(0x5) = 0 0 write_nocancel(0x2, "This application failed to start because it could not find or load the Qt platform plugin \"cocoa\".\n\nReinstalling the application may fix this problem.\n\0", 0x97) = 151 0 sigprocmask(0x3, 0x7FFF5C8FE6B4, 0x0) = 0x0 0 __pthread_sigmask(0x3, 0x7FFF5C8FE6C0, 0x0) = 0 0 __pthread_kill(0x603, 0x6, 0x0) = 0 0 kevent64(0x4, 0x0, 0x0) = -1 Err#4You can see this QT app trying to look into MacOS/platforms, once i copied my libqcocoa.dylib plugin (its path were modified by install_name_tool command as per @mfitzp's answer) there, my application worked like charm.
BTW it is advisable by MAC codesigning guide to have this directory structure correctly setup,