Re: not finding "cocoa"

1,915 views
Skip to first unread message

David Cortesi

unread,
Jan 15, 2015, 2:36:47 PM1/15/15
to pyins...@googlegroups.com
I said that under Python 3, pyinstaller made a one-folder bundle of my PyQt5 app that failed with the message,

> This application failed to start because it could not find or load the Qt platform plugin "cocoa".

Glenn Ramsey said,

> On my builds of a working app the libqcocoa.dylib file goes here:
>    Contents/MacOS/qt5_plugins/platforms
> Pyinstaller does this for me, though.

It does it for me, too. Well, it copies into the dist folder, "libqcocoa" (no suffix). I manually copied in "libqcocoa.dylib" from the Qt5.4 distribution also, but the app terminates the same way.

I do not know where this request is coming from, because I executed the following in the dist folder:

   otool -L * | grep ocoa

and the only files that mentioned Cocoa or cocoa as an id or a link were cocoa itself (which is there) and libqcocoa and libqcocoa.dylib. And then only in the first line, which is the lib's id, not a link; or as a link to /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa, which definitely exists.

Glenn Ramsey

unread,
Jan 15, 2015, 5:08:11 PM1/15/15
to pyins...@googlegroups.com
On 16/01/15 08:36, David Cortesi wrote:
> I said that under Python 3, pyinstaller made a one-folder bundle of my PyQt5 app
> that failed with the message,
>
>> This application failed to start because it could not find or load the Qt
> platform plugin "cocoa".
>
> Glenn Ramsey said,
>
>> On my builds of a working app the libqcocoa.dylib file goes here:
>> Contents/MacOS/qt5_plugins/platforms
>> Pyinstaller does this for me, though.
>
> It does it for me, too. Well, it copies into the dist folder, "libqcocoa" (no
> suffix). I manually copied in "libqcocoa.dylib" from the Qt5.4 distribution
> also, but the app terminates the same way.

You can't do that. You need to rewrite all of the dependency paths. On my build
it looks like this:

My.app/Contents/MacOS/qt5_plugins/platforms$ otool -L libqcocoa.dylib
libqcocoa.dylib:
@loader_path/../../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 19.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility
version 2.0.0, current version 155.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
version 1.0.0, current version 275.0.0)
@loader_path/../../QtPrintSupport (compatibility version 5.2.0, current version
5.2.1)
@loader_path/../../QtWidgets (compatibility version 5.2.0, current version 5.2.1)
@loader_path/../../QtGui (compatibility version 5.2.0, current version 5.2.1)
@loader_path/../../QtCore (compatibility version 5.2.0, current version 5.2.1)
@loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version
1.2.8)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility
version 1.0.0, current version 1.0.0)
@loader_path/../../libgthread-2.0.0.dylib (compatibility version 3801.0.0,
current version 3801.2.0)
@loader_path/../../libglib-2.0.0.dylib (compatibility version 3801.0.0, current
version 3801.2.0)
@loader_path/../../libintl.8.dylib (compatibility version 10.0.0, current
version 10.2.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 45.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version
1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 744.18.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility
version 45.0.0, current version 1187.37.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 57.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 945.16.0)

>
> I do not know where this request is coming from, because I executed the
> following in the dist folder:
>
> otool -L * | grep ocoa
>
> and the only files that mentioned Cocoa or cocoa as an id or a link were cocoa
> itself (which is there) and libqcocoa and libqcocoa.dylib. And then only in the
> first line, which is the lib's id, not a link; or as a link to
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa, which definitely
> exists.

It is probably not finding the Qt framework binaries. PyInstaller puts them in
Contents/MacOS without a suffix as you can see in the listing above.

Glenn

David Cortesi

unread,
Jan 16, 2015, 4:14:02 PM1/16/15
to pyins...@googlegroups.com
I said that under Python 3, pyinstaller made a one-folder bundle of my  PyQt5 app that failed with the message,
 
> This application failed to start because it could not find or load the Qt  platform plugin "cocoa".
 
Glenn Ramsey said,

>On my build it looks like this:
> My.app/Contents/MacOS/qt5_plugins/platforms$ otool -L libqcocoa.dylib...

at which point I finally twigged to the different directory structure, including My.app/Contents.

You are building a mac app bundle, which I was not, merely a one-folder build.

So I added the --one-file and --windowed options and ... huh. I still get a folder dist/myapp containing a mess of libraries and a "myapp" executable. No myapp.app with Contents etc.

So is the --one-file, --windowed Mac OS app-bundle feature not yet supported for Python3? That would explain some of my problem.

Glenn Ramsey

unread,
Jan 18, 2015, 4:05:46 PM1/18/15
to pyins...@googlegroups.com
Not sure about about the python3 support but to build a Mac bundle you need to
use the BUNDLE command and --onedir mode.

Mine looks like this:

app = BUNDLE(coll,
name=os.path.join('dist', 'MyApp.app'),
appname="MyApp",
version = "0.1"
)

where coll is the output from the COLLECT command.

Glenn

Martin Zibricky

unread,
Jan 20, 2015, 3:37:56 AM1/20/15
to pyins...@googlegroups.com
On Monday 19 of January 2015 10:05:41 Glenn Ramsey wrote:
> > I said that under Python 3, pyinstaller made a one-folder bundle of
> > my PyQt5 app that failed with the message,
> >
> >
> >
> >> This application failed to start because it could not find or load the
> >> Qt
> >
> > platform plugin "cocoa".

Could you find out if the rthook
./PyInstaller/loader/rthooks/pyi_rth_qt5plugins.py is bundled with the
executable?

See file ./utils/archive_viewer.py
signature.asc

David Cortesi

unread,
Jan 22, 2015, 4:14:49 PM1/22/15
to pyins...@googlegroups.com
Apologies for a messed-up report earlier. I had attempted pyinstaller -w myscript.spec, but the spec file was left over from previous runs that did not specify -w. My bad.

When I ran pyinstaller -w -i iconfile.icns myscript.py, a correct Mac OS app folder was created, it even sported the desired icon. So MacOS bundle is in and working for python 3.

But when double-clicked, the app failed with SIGABRT. Running from the command line, myscript.app/Contents/MacOS/myscript produces the console message,

> This application failed to start because it could not find or load the Qt platform plugin "cocoa".
> Reinstalling the application may fix this problem.
> Abort trap: 6

"find -name '*oco*'" gets no hits in the .app folder. Searching the files in the build folder, I do not find the string "oco" in any of the files, the warn file or any of the out00-* files.

Using otool -L Qt* | grep oco shows that four of the Qt DLLs refer to /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa but that should not be a problem. None of the Py*.so files refer to "oco" on this test.

Martin asked,


> Could you find out if the rthook ./PyInstaller/loader/rthooks/pyi_rth_qt5plugins.py
> is bundled with the executable?

Yes it is. archive_viewer reports,

 (1468099, 288, 381, 1, b'm', b'struct'),
 (1468387, 1192, 2059, 1, b'm', b'pyi_os_path'),
 (1469579, 4596, 10188, 1, b'm', b'pyi_archive'),
 (1474175, 4644, 12494, 1, b'm', b'pyi_importers'),
 (1478819, 2005, 4781, 1, b's', b'_pyi_bootstrap'),
 (1480824, 706, 1422, 1, b's', b'pyi_rth_qt5plugins'),
 (1481530, 4323, 13642, 1, b's', b'pyi_carchive'),
 (1485853, 25707, 82120, 1, b's', b'myscript')]

Glenn Ramsey

unread,
Jan 22, 2015, 5:00:48 PM1/22/15
to pyins...@googlegroups.com
Hi David,

On 23/01/15 10:14, David Cortesi wrote:
> Apologies for a messed-up report earlier. I had attempted pyinstaller -w
> myscript.spec, but the spec file was left over from previous runs that did not
> specify -w. My bad.
>
> When I ran pyinstaller -w -i iconfile.icns myscript.py, a correct Mac OS app
> folder was created, it even sported the desired icon. So MacOS bundle is in and
> working for python 3.
>
> But when double-clicked, the app failed with SIGABRT. Running from the command
> line, myscript.app/Contents/MacOS/myscript produces the console message,
>
>> This application failed to start because it could not find or load the Qt
> platform plugin "cocoa".
>> Reinstalling the application may fix this problem.
>> Abort trap: 6
>
> "find -name '*oco*'" gets no hits in the .app folder. Searching the files in the
> build folder, I do not find the string "oco" in any of the files, the warn file
> or any of the out00-* files.

That still looks like your problem - PyInstaller appears to not be packaging
libqcocoa.dylib. Does libqcocoa.dylib exist in your Qt installation? Do the logs
show any warnings that it couldn't be found?

>
> Using otool -L Qt* | grep oco shows that four of the Qt DLLs refer to
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa but that should not
> be a problem. None of the Py*.so files refer to "oco" on this test.

I don't think you should expect the Py*.so to refer to the Cocoa libs. The Qt
libs should link to Cocoa as your output shows.

Glenn

David Cortesi

unread,
Jan 23, 2015, 8:19:29 PM1/23/15
to pyins...@googlegroups.com

The file libqcocoa.dylib does exist in the Qt distribution.

Definitely the stock pyinstaller -w operation does not include it or anything else with a name like "*coco*" in the output bundle.

I modified the spec file to read as follows:

# -*- mode: python -*-
a = Analysis(['/Users/dcortesi/Dropbox/David/PPQT/CoBro/cobro.py'],
             pathex=['/Users/dcortesi/Desktop/scratch/pyinst'],
             hiddenimports=[],
             hookspath=None,
             runtime_hooks=None)
pyz = PYZ(a.pure)

exe = EXE(pyz,
          a.scripts,
          exclude_binaries=True,
          name='cobro',
          debug=False,
          strip=None,
          upx=True,
          console=False , icon='cobro.icns')

a.binaries += [ ('cocoa', '/Developer/5.4/clang_64/plugins/platforms/libqcocoa.dylib', 'BINARY' ) ]
a.binaries += [ ('libqcocoa', '/Developer/5.4/clang_64/plugins/platforms/libqcocoa.dylib', 'BINARY' ) ]
a.binaries += [ ('libqcocoa.dylib', '/Developer/5.4/clang_64/plugins/platforms/libqcocoa.dylib', 'BINARY' ) ]

coll = COLLECT(exe,
               a.binaries,
               a.zipfiles,
               a.datas,
               strip=None,
               upx=True,
               name='cobro')
app = BUNDLE(coll,
             name='cobro.app',
             icon='cobro.icns')

When this is run, the desired lib does appear, in three copies under three names, in the cobro.app bundle:

$ find dist/cobro.app -name '*coco*'
dist/cobro.app/Contents/MacOS/cocoa
dist/cobro.app/Contents/MacOS/libqcocoa
dist/cobro.app/Contents/MacOS/libqcocoa.dylib

Nevertheless, when the app is executed it dies as before with the abort,

This application failed to start because it could not find or load the Qt platform plugin "cocoa".

I go into the "hooks" folder and execute cat hook-PyQt5* | grep cocoa and get no output, so it is not mentioned in a hook. (Nor in PyQt4*)

Any ideas welcome...


Reply all
Reply to author
Forward
0 new messages